2026上半年5月软考系统架构设计师考试《案例分析》真题及答案

2026上半年5月软考系统架构设计师考试《案例分析》真题及答案一、案例分析题（每题15分，共75分）###试题一（共15分）阅读以下关于软件系统架构设计的叙述，回答问题1至问题3。某大型电商平台计划对其订单处理系统进行升级改造。该平台在每年"双11"期间需应对峰值每秒10万笔以上的订单创建请求，同时要求系统在部分服务节点失效时仍能继续提供订单查询与创建服务。平台技术团队提出了三种候选架构方案：方案A：采用传统的单体应用架构，将订单、库存、支付等模块部署在同一个应用服务器集群中，通过负载均衡器对外提供服务。方案B：采用微服务架构，将订单、库存、支付、物流等功能拆分为独立的微服务，每个服务独立部署、独立扩展，服务间通过轻量级HTTP/REST接口通信。方案C：采用面向服务的架构（SOA），将核心业务功能封装为粗粒度的服务，通过企业服务总线（ESB）进行服务间的消息路由与协议转换。【问题1】（5分）请分别从可修改性、可伸缩性、可用性三个质量属性角度，简要分析方案B相对于方案A的优势。【问题2】（5分）在方案B的微服务架构中，服务间通信可能引入数据一致性、分布式事务等问题。请列举两种解决微服务间数据一致性的常见策略，并简要说明其基本原理。【问题3】（5分）请结合该电商平台的业务特点，说明方案C（SOA）与方案B（微服务）在服务粒度划分上的主要区别，并指出哪种方案更适合该场景，说明理由。答案：【问题1】（1）可修改性：方案B将系统拆分为多个独立的微服务，每个服务可独立开发、测试、部署，修改单个服务时无需重新部署整个系统，降低了修改的波及范围；方案A中任何模块的修改都可能导致整个应用重新构建和部署，修改成本高、风险大。（2）可伸缩性：方案B支持对单个微服务进行独立的水平伸缩，例如在促销期间仅对订单服务、支付服务增加实例，而无需扩展整个系统，资源利用率更高；方案A只能对整个应用集群进行统一伸缩，无法针对瓶颈模块精细扩容。（3）可用性：方案B中单个微服务出现故障时，故障被限制在服务边界内，其他服务仍可继续运行，配合熔断、隔离等机制可有效防止故障蔓延；方案A中任何模块的异常（如内存泄漏、线程阻塞）都可能导致整个应用进程崩溃，造成全局性可用性下降。【问题2】（1）两阶段提交（2PC）协议：通过引入事务协调者（Coordinator），分准备阶段和提交阶段两个阶段协调多个参与者的提交行为，保证所有参与者在同一事务中要么全部提交、要么全部回滚，从而实现强一致性。（2）最终一致性方案（如本地消息表、事务消息）：将分布式事务拆分为多个本地事务，通过消息中间件（如RocketMQ、Kafka）异步传递事务状态，配合消息重试与对账机制，保证各服务间的数据在最终时刻达到一致状态，适用于对实时一致性要求不高的业务场景。（3）Saga模式：将一个分布式事务拆分为多个本地事务（子事务），每个子事务都有对应的补偿操作，按照业务流程依次执行各子事务，当某一步失败时，反向依次执行补偿操作进行回滚，从而在牺牲强一致性的前提下保证业务最终一致性。（答出其中任意两种即可，每种2.5分）【问题3】方案C（SOA）强调服务的粗粒度划分，服务通常对应企业级的业务功能（如订单管理、客户管理），服务间通过ESB进行集中式通信和协议转换；方案B（微服务）更强调服务的细粒度划分，每个服务聚焦于单一业务能力（如订单创建、库存扣减、支付回调），服务间采用轻量级通信机制。该场景更适合方案B（微服务架构）。理由如下：（1）该平台订单并发量极高，微服务架构支持对热点服务（如订单创建服务）进行精细化的独立伸缩，资源利用率和弹性更好。（2）微服务采用去中心化的轻量级通信，避免了ESB成为性能瓶颈和单点故障。（3）电商业务需求变化频繁，微服务独立部署、独立演进的特点更有利于快速迭代。（答出方案B得1分，理由答出任意两点得3分，表述完整再得1分）###试题二（共15分）阅读以下关于软件架构评估的叙述，回答问题1至问题3。某省级医疗保险信息系统拟进行升级改造，该系统需接入全省2000余家定点医院和药店，日均交易量约300万笔，涉及参保人员基本信息管理、医保费用实时结算、药品目录管理、基金监管等核心业务。系统架构师团队采用ATAM（ArchitectureTradeoffAnalysisMethod）方法对候选架构进行评估。评估过程中，团队识别出以下架构敏感点与权衡点：-敏感点S1：数据库读写分离策略，读操作与写操作的比例约为8：2。-敏感点S2：结算服务的线程池大小配置。-权衡点T1：采用同步调用方式保证结算数据的强一致性，但会增加接口响应时间。-权衡点T2：采用本地缓存降低药品目录的查询延迟，但会引入缓存与数据库数据不一致的风险。【问题1】（5分）请说明ATAM方法中"敏感点"和"权衡点"的含义，并判断上述S1、S2、T1、T2中哪些属于敏感点、哪些属于权衡点。【问题2】（5分）在ATAM评估过程中，需要建立质量属性效用树。请以该医疗保险系统为例，写出"性能"和"可用性"两个质量属性各两条质量属性场景（无需量化指标，描述刺激、来源、环境、响应即可）。【问题3】（5分）针对权衡点T2（本地缓存与数据一致性），请提出一种能够降低数据不一致风险的架构设计方案。答案：【问题1】（1）敏感点是指一个或多个构件（或构件之间的关系）的特性，它决定了某个质量属性是否能得到满足，即架构中与某个质量属性密切相关的设计决策点；权衡点是指影响多个质量属性的敏感点，对某个质量属性的改善可能以降低另一个质量属性为代价。（2）S1属于敏感点（数据库读写分离直接决定性能质量属性的满足程度）；S2属于敏感点（线程池大小直接影响系统的并发处理能力）；T1属于权衡点（同步调用保证了数据一致性，但牺牲了响应时间性能）；T2属于权衡点（本地缓存提升了查询性能，但引入了数据不一致的风险）。【问题2】（1）性能质量属性场景：场景一：来源为参保人员在定点医院刷卡结算，刺激为在业务高峰时段（如工作日上午9：00-11：00）发起医保费用实时结算请求，环境为系统处于正常负载状态，响应为系统在3秒内返回结算结果，且结算服务的吞吐量不低于每秒500笔。场景二：来源为医保经办机构工作人员，刺激为并发查询某药品在不同医院的报销比例信息，环境为药品目录数据量约50万条，响应为系统在1秒内返回查询结果，且查询接口的吞吐量不低于每秒1000次。（2）可用性质量属性场景：场景一：来源为数据库管理员，刺激为结算数据库主节点发生宕机，环境为系统处于正常运行状态，响应为系统在30秒内自动切换到备用数据库节点，切换期间结算服务不中断或中断时间不超过10秒。场景二：来源为网络管理员，刺激为某定点医院与医保中心之间的网络链路发生故障，环境为部分医院正在发起实时结算请求，响应为系统检测到故障并在5秒内启用消息队列缓冲结算请求，待网络恢复后自动补发，参保人员无感知。【问题3】可采用以下架构设计方案（答出任意三种即可）：（1）引入缓存失效通知机制：当药品目录数据在数据库中发生变更时，由数据变更服务主动向缓存集群发送失效通知（或通过消息中间件广播失效事件），各应用节点的本地缓存及时删除或更新对应缓存项，缩短数据不一致的时间窗口。（2）设置合理的缓存过期时间（TTL）：为本地缓存设置较短的过期时间（如5分钟），即使未收到失效通知，缓存数据也会在短时间内自动过期并重新从数据库加载，保证最终一致性。（3）采用版本号或时间戳机制：在缓存数据中记录版本号或更新时间戳，应用在读取缓存时校验数据版本，若发现版本落后则回源数据库读取最新数据并更新缓存。（4）关键数据（如医保报销比例、结算参数）不采用本地缓存，改为通过分布式缓存（如Redis）统一管理，利用分布式缓存的主从复制和持久化机制在性能与一致性之间取得平衡。（5）增加缓存与数据库的定期对账任务：定时扫描数据库中的药品目录变更记录，与缓存内容进行比对，自动修复不一致的缓存数据。###试题三（共15分）阅读以下关于系统可靠性设计的叙述，回答问题1至问题3。某航空公司的机票预订系统承担着航班查询、座位预订、出票、退改签等核心业务，系统要求全年可用性达到99.99%。目前系统采用双机热备架构，数据库使用OracleRAC集群。近期发生了一次因应用服务器内存泄漏导致的服务中断事故，事故持续40分钟。为此，架构师团队计划对系统进行可靠性改造。【问题1】（5分）请计算该机票预订系统当前的年度停机时间是否满足99.99%的可用性目标（全年按365天计算）。若仅考虑本次事故，请判断当前可用性是否达标。【问题2】（5分）针对应用服务器内存泄漏问题，请从"错误检测"和"错误恢复"两个角度提出至少三种可靠性设计策略。【问题3】（5分）为应对数据库层的单点故障风险，架构师计划引入数据库读写分离方案。请说明读写分离方案可能引入的"数据一致性"问题，并提出两种解决该问题的技术手段。答案：【问题1】全年总时间=36599.99%可用性对应的允许停机时间为：525600本次事故停机40分钟<52.56分钟，因此仅考虑本次事故时，系统当前可用性满足99.99%的目标。（计算过程正确得3分，结论正确得2分）【问题2】（1）错误检测策略一：建立JVM内存监控机制，通过监控平台（如Zabbix、Prometheus）实时采集应用服务器的堆内存使用量、GC频率、FullGC耗时等指标，设置内存使用率阈值（如85%），当指标超过阈值时触发告警。（2）错误检测策略二：在应用层增加内存泄漏自检功能，定期（如每小时）记录关键业务对象的创建数量与释放数量，通过对比分析识别可疑的对象增长趋势。（3）错误恢复策略一：采用应用服务器进程自动重启机制，当检测到内存使用率持续超过阈值（如95%）或发生OutOfMemoryError时，由守护进程自动重启应用实例，并通过负载均衡器摘除故障节点流量，实现无感知切换。（4）错误恢复策略二：采用滚动发布与优雅下线机制，每次发布新版本时逐个重启应用实例，并在重启前通过负载均衡器将该实例的流量切换至其他健康节点，避免因单个实例故障导致整体服务不可用。（5）错误恢复策略三：采用多实例冗余部署与自动伸缩机制，将应用服务器部署为至少3个实例，当某个实例因内存问题被重启或隔离时，其余实例继续承担流量，同时通过容器编排平台（如Kubernetes）自动拉起新实例补充容量。（答出任意三种即可，每种策略得2分，最多得5分）【问题3】读写分离方案中，应用将写操作发送到主数据库，将读操作发送到从数据库，主库与从库之间通过异步复制同步数据。由于异步复制存在复制延迟，可能导致应用在写入数据后立即从从库读取时读不到最新数据，产生"读写不一致"问题。解决该问题的技术手段（答出任意两种即可）：（1）关键读请求路由到主库：在数据访问层（或DAL中间件）中配置路由规则，对于实时性要求高的读操作（如用户刚提交订单后的订单详情查询），强制路由到主库执行，保证强一致；对实时性要求低的读操作（如历史订单查询）则路由到从库。（2）采用半同步复制：将数据库的主从复制模式由全异步改为半同步复制，即主库在提交事务时，等待至少一个从库确认收到binlog日志后才向应用返回成功，从而缩短复制延迟窗口，降低不一致概率。（3）引入分布式缓存中间层：对于刚写入的数据，应用在写入主库的同时将该数据写入分布式缓存（如Redis），后续读操作优先读取缓存，缓存未命中时再查询从库，从而避免因复制延迟导致的旧数据读取。（4）会话级读写一致性：在应用层根据用户会话标识，将同一用户在同一会话内的所有读写请求均路由到主库，保证单个用户维度的读写一致性。###试题四（共15分）阅读以下关于Web系统架构设计的叙述，回答问题1至问题3。某在线教育平台计划开发一套支持10万用户同时在线的视频课程学习系统。系统需支持课程视频点播、直播授课、在线作业提交与批改、学习进度记录、师生互动讨论等功能。技术团队初步确定了以下架构设计决策：决策一：前端采用单页应用（SPA）架构，使用Vue.js框架，后端提供RESTfulAPI。决策二：视频点播与直播服务采用CDN（内容分发网络）进行加速。决策三：学习进度、互动讨论等高频读写数据采用Redis缓存+MySQL持久化存储的组合方案。决策四：系统部署在云平台上，采用弹性伸缩策略应对流量高峰。【问题1】（5分）请说明RESTfulAPI设计应满足的五个关键约束（或特征），并结合该系统列举一个符合RESTful风格的资源URI设计示例。【问题2】（5分）请从CDN加速原理角度，说明视频点播服务采用CDN后，用户在播放视频时的请求处理过程（从用户发起播放请求到视频开始播放，简述关键步骤）。【问题3】（5分）针对决策三，请分析"Redis缓存+MySQL"组合方案可能出现的缓存与数据库数据不一致的场景，并提出两种保证缓存一致性的策略。答案：【问题1】RESTfulAPI设计应满足的五个关键约束：（1）客户端-服务器（Client-Server）：客户端与服务器分离，客户端通过HTTP协议访问服务器资源，服务器不关心客户端状态。（2）无状态（Stateless）：服务器不保存客户端请求之间的上下文状态，每个请求都包含处理该请求所需的全部信息，会话状态由客户端维护。（3）可缓存（Cacheable）：响应数据应显式或隐式地标识是否可缓存，客户端可缓存响应内容以减少重复请求，提升性能。（4）统一接口（UniformInterface）：通过标准化的HTTP方法（GET、POST、PUT、DELETE等）对资源进行操作，资源通过URI唯一标识，使用标准状态码（200、404、500等）表示请求结果。（5）分层系统（LayeredSystem）：客户端通常无法感知是否直接连接服务器，中间层（如代理、网关、负载均衡器）可拦截或转发请求，不影响客户端与服务器的交互。（6）按需代码（CodeonDemand，可选）：服务器可向客户端传输可执行代码（如JavaScript）以扩展客户端功能。（答出任意五个即可，每个0.8分，最多4分；URI示例1分）URI设计示例：-GET/api/v1/courses/{courseId}/videos——获取某课程的视频列表-POST/api/v1/courses/{courseId}/homework——提交课程作业-PUT/api/v1/users/{userId}/progress/{courseId}——更新用户学习进度-GET/api/v1/courses/{courseId}/discussions?page=1&size=20——分页获取课程讨论区帖子（答出任意一个即可）【问题2】用户播放视频时，CDN加速的请求处理过程如下：（1）用户在浏览器或客户端中点击播放视频，客户端向视频播放地址（通常为CDN加速域名）发起HTTP请求。（2）本地DNS系统对CDN加速域名进行解析，返回CDN全局负载均衡系统（GSLB）的IP地址。（3）GSLB根据用户的地理位置、网络运营商、各CDN边缘节点的负载情况，选择一台最优的边缘节点服务器，并将该节点的IP地址返回给客户端。（4）客户端向该CDN边缘节点发起视频资源请求。（5）边缘节点检查本地缓存中是否存在该视频资源（或视频分片）。若命中缓存，则直接返回视频流；若未命中，则边缘节点向源站（视频源服务器）发起回源请求，获取视频资源后缓存在本地，同时将视频流返回给客户端。（6）客户端开始播放视频，后续的视频分片请求优先由边缘节点直接响应，无需再回源站获取。【问题3】缓存与数据库数据不一致的典型场景：场景一：应用先更新数据库、后删除缓存，在删除缓存前有并发读请求读取到缓存中的旧数据。场景二：应用先删除缓存、后更新数据库，在更新数据库前有并发读请求发现缓存未命中，回源数据库读取到旧数据并回填缓存，导致缓存中长时间保留旧数据。场景三：更新数据库成功但删除缓存失败（或更新缓存失败），导致缓存与数据库数据不一致。保证缓存一致性的策略（答出任意两种即可）：（1）CacheAsidePattern（旁路缓存）+延迟双删：更新数据库后先删除缓存，间隔一段时间（如500毫秒）后再次删除缓存。第二次删除用于清除并发读请求在第一次删除后回填的旧数据缓存，降低不一致时间窗口。（2）消息队列异步删除缓存：更新数据库成功后，向消息队列发送一条缓存删除消息，由消费者异步执行缓存删除操作。若删除失败，可通过消息重试机制多次尝试，最终保证缓存被删除。（3）设置合理的缓存过期时间（TTL）：为缓存数据设置较短的过期时间（如5-10分钟），即使发生不一致，缓存也会在TTL到期后自动过期，应用重新从数据库加载最新数据，实现最终一致性。（4）订阅数据库binlog变更：通过Canal等中间件订阅MySQL的binlog日志，解析出数据变更事件后，异步更新或删除对应缓存项，实现缓存与数据库的准实时同步。###试题五（共15分）阅读以下关于设计模式应用的叙述，回答问题1至问题3。本题为选答题，请从试题五（Java版）和试题六（C++版）中任选一题作答。某企业开发一套多格式报表导出系统，支持导出PDF、Excel、CSV三种格式的报表。报表的生成过程包含数据查询、数据转换、格式渲染、文件输出四个步骤。目前系统采用硬编码方式，在业务代码中通过if-else分支判断目标格式并执行相应的导出逻辑，导致代码重复、扩展困难。架构师计划使用设计模式对系统进行重构。【问题1】（5分）请从以下设计模式中选择两种最适合该场景的设计模式，并说明选择理由。A.工厂方法模式（FactoryMethod）B.建造者模式（Builder）C.策略模式（Strategy）D.模板方法模式（TemplateMethod）E.装饰器模式（Decorator）【问题2】（5分）请针对你选择的设计模式，画出相应的类图（无需完整代码，描述类名、关键方法及关系即可）。【问题3】（5分）请用Java语言（或C++语言）写出该设计模式的核心接口或抽象类定义，以及PDF格式导出实现类的关键代码片段。答案：【问题1】选择A（工厂方法模式）和D（模板方法模式）。选择理由：（1）模板方法模式：报表导出的四个步骤（数据查询、数据转换、格式渲染、文件输出）的算法骨架是固定的，不同格式的导出只是其中"格式渲染"步骤的具体实现不同，符合模板方法模式"定义算法骨架、将可变步骤延迟到子类实现"的适用场景。（2）工厂方法模式：系统需要根据用户选择的格式（PDF、Excel、CSV）动态创建对应的导出器对象，工厂方法模式将对象的创建延迟到子类，由具体工厂决定实例化哪个导出器类，避免了业务代码中的if-else分支。（3）策略模式也可作为备选（将不同格式的导出算法封装为策略类），但本题中导出步骤的骨架固定，模板方法模式更为贴切；工厂方法模式用于封装对象创建逻辑，两者搭配使用可同时解决"创建"和"算法变化"两个问题。【问题2】类图描述：<<abstract>>

ReportExporterReportExporterFactory（抽象工厂）

+exportReport():void+createExporter():ReportExporter

+queryData():void

+transformData():void^^

#renderContent():void||

+writeFile():void||

||

^||

|||

+++||

|||||

PdfExporterExcelExporterCsvExporterPdfExporterFactoryExcelExporterFactory类图说明：（1）抽象类ReportExporter定义了导出报表的模板方法exportReport()，该方法依次调用queryData()、transformData()、renderContent()、writeFile()四个步骤，其中queryData()、transformData()、writeFile()为公共方法（在抽象类中实现），renderContent()为抽象方法，由子类实现。（2）PdfExporter、ExcelExporter、CsvExporter继承ReportExporter，分别实现renderContent()方法，完成PDF、Excel、CSV格式的渲染。（3）抽象工厂ReportExporterFactory声明工厂方法createExporter()，PdfExporterFactory、ExcelExporterFactory等具体工厂分别创建对应的导出器对象。【问题3】Java版核心代码：//抽象类：报表导出器（模板方法模式）

publicabstractclassReportExporter{

//模板方法：定义报表导出的算法骨架

publicfinalvoidexportReport(){

queryData();

transformData();

renderContent();

writeFile();

}

protectedvoidqueryData(){

System.out.println("从数据库查询报表数据...");

}

protectedvoidtransformData(){

System.out.println("将数据转换为统一格式...");

}

//抽象方法：由子类实现不同格式的渲染

protectedabstractvoidrenderContent();

protectedvoidwriteFile(){

System.out.println("将渲染结果写入输出文件...");

}

}

//具体子类：PDF导出器

publicclassPdfExporterextends