2025年全国计算机技术与软件专业技术资格(水平)考试软件架构师试卷及答案

2025年全国计算机技术与软件专业技术资格(水平)考试软件架构师试卷及答案一、单项选择题（每题1分，共20分。每题只有一个最符合题意的选项）1.在微服务架构中，下列哪项最能直接降低服务间调用的平均延迟？A.引入API网关统一路由B.使用gRPC替代RESTC.所有服务共享同一数据库D.将日志改为异步批量写入答案：B解析：gRPC基于HTTP/2与二进制协议，序列化效率远高于JSON，网络传输字节数减少30%~60%，在同等带宽下可显著降低调用延迟。A仅减少客户端并发连接数，C违背微服务数据库独立原则，D与调用延迟无直接因果关系。2.某电商系统采用CQRS模式，命令端使用MySQL，查询端使用Elasticsearch。若要求命令端写入后查询端立即可见，最合适的同步策略是：A.双写B.基于Binlog的CDCC.事务消息队列D.查询端定期全量拉取答案：B解析：BinlogCDC（如Canal）异步但毫秒级延迟，对业务代码零侵入，且能保证顺序；双写存在分布式事务难题；事务消息需改业务；定期拉取无法满足“立即”。3.在4+1视图模型中，用于描述“系统并发进程、线程、同步”的视图是：A.逻辑视图B.进程视图C.物理视图D.开发视图答案：B解析：进程视图（ProcessView）聚焦运行时并发与同步，逻辑视图描述功能结构，物理视图映射硬件，开发视图聚焦模块划分与程序包。4.某金融核心系统要求RPO=0、RTO<30秒，同城双活、异地冷备。下列方案中，最合理的是：A.同城双数据库采用异步复制，异地使用快照备份B.同城双数据库采用半同步复制，异地使用延迟备库C.同城双数据库采用组复制（同步），异地使用异步备库D.同城双数据库采用共享存储，异地使用磁带备份答案：C解析：组复制（如MySQLGroupReplication）保证同城数据强一致，RPO=0；异地异步虽RPO>0，但题目仅要求同城双活RPO=0，异地冷备可接受分钟级RPO。半同步仍可能丢数据，共享存储存在脑裂风险。5.在DDD分层架构中，领域服务（DomainService）最适合放以下哪种逻辑？A.调用第三方支付网关的HTTP接口B.根据促销规则计算订单折扣C.将领域对象转换为DTOD.记录用户操作审计日志答案：B解析：促销规则属于领域行为，但又不天然归属于某个实体，由领域服务承载最合适。A属基础设施层，C属应用层或接口层，D属横切关注点。6.某系统使用SpringCloudGateway，需在网关中实现“基于JWT中userId做限流10次/秒”，应扩展的过滤器接口是：A.GlobalFilterB.GatewayFilterC.AbstractGatewayFilterFactoryD.WebFilter答案：A解析：GlobalFilter对所有路由生效，无需在配置中显式绑定，适合全局横切需求；GatewayFilter需配置到具体路由；WebFilter属于Servlet体系，Gateway基于Netty。7.在CAP理论中，当网络分区发生时，分布式缓存系统选择“继续提供服务但可能返回旧数据”，这属于：A.CPB.APC.CAD.无法归类答案：B解析：AP系统牺牲一致性（C）保证可用性（A），允许读旧数据。8.某团队将单体系统拆分为微服务后，发现“同一业务操作需调用5个服务，网络开销占比从5%升至35%”，最先应考虑的优化手段是：A.将所有服务合并回单体B.引入服务编排层进行并行调用C.使用服务网格（ServiceMesh）D.采用领域驱动设计重划边界答案：D解析：网络开销激增往往源于服务边界划分错误（把本地事务内的操作拆到远程），应回溯领域模型，合并错误拆分的微服务，而非单纯技术层优化。9.在TOGAFADM周期中，用于“确认架构实施符合预期”的阶段是：A.阶段E（机会与解决方案）B.阶段F（迁移规划）C.阶段G（实施治理）D.阶段H（架构变更管理）答案：C解析：阶段G通过架构契约和合规审查确保实施不偏离架构。10.某系统采用Kafka做事件总线，要求“消息恰好一次（exactlyonce）投递到下游MySQL”，正确做法是：A.开启Kafka的enable.idempotence=trueB.下游使用幂等键+Kafka事务消息C.下游使用MySQL事务+手动提交offsetD.使用KafkaStreams的exactlyonce语义并输出到MySQL答案：D解析：KafkaStreams在0.11后支持端到端exactlyonce，借助事务型生产与幂等消费，输出到MySQL时可利用KafkaConnect的JDBCSink实现事务性写入；A仅保证生产端幂等，B、C仍需自己实现事务对齐。11.在性能测试中，下列指标最能直接反映“系统可扩展性”好坏？A.90th延迟B.并发用户数的线性扩展比C.CPU利用率D.错误率答案：B解析：线性扩展比=吞吐量(2N节点)/吞吐量(N节点)，越接近2表示扩展性越好；其余指标反映性能或稳定性，而非扩展能力。12.某云原生应用使用Kubernetes，Pod内存使用呈“锯齿形”周期性OOMKilled，最可能原因是：A.未设置limitB.未设置requestC.JVM堆大于limitD.存活探针周期过长答案：C解析：JVM默认最大堆为宿主机内存的1/4，若Podlimit小于该值，堆外内存+堆内内存易超limit，触发OOMKill；锯齿形体现GC后下降，业务高峰再上涨。13.在分层架构中，下列依赖规则符合“依赖倒置原则”的是：A.领域层依赖基础设施层B.应用层依赖领域层C.基础设施层依赖领域层D.接口层依赖基础设施层答案：C解析：依赖倒置要求高层不依赖低层，两者都依赖抽象；领域层为高层，基础设施为实现细节，应让基础设施依赖领域层定义的接口。14.某系统使用SeataAT模式做分布式事务，当分支事务update语句执行后、全局事务提交前，该记录被另一本地事务update，Seata会：A.自动重试直到成功B.回滚全局事务并抛异常C.跳过锁检查以提高性能D.提交全局事务答案：B解析：SeataAT模式通过全局锁保证写隔离，若本地事务绕过Seata修改数据，提交时发现镜像不一致，会触发回滚。15.在Serverless架构中，下列哪项最能体现“弹性伸缩”优势？A.按调用次数计费B.冷启动时间<100msC.并发实例数自动随请求量增长D.函数代码包<50MB答案：C解析：自动水平扩展是弹性核心；A是计费模式，B是性能指标，D是限制条件。16.某高并发系统采用读写分离，主从延迟300ms，用户刚下单后刷新列表看不到订单，可用“读写一致性”方案是：A.强制所有读走主库B.使用“写后读”令牌，在300ms内路由到主库C.增加从库节点D.使用缓存穿透答案：B解析：写后读令牌（如MySQL的session级位点）可在延迟窗口内把特定用户的读请求路由到主库，兼顾一致性与性能；A退化为单点，C不解决延迟，D无关。17.在架构评估中，使用“质量属性效用树”最先应完成：A.列出所有场景B.识别质量属性C.与业务方确认优先级D.分配权重答案：B解析：效用树自顶向下，先识别质量属性（性能、可用性等），再细化场景。18.某系统使用RedisCluster，节点数从8扩容到16，数据迁移期间出现“MOVED”重定向骤增，说明：A.客户端未缓存槽位映射B.集群未开启AOFC.节点故障D.网络分区答案：A解析：RedisCluster客户端应在本地缓存槽位节点映射，若每次请求都随机节点，会收到MOVED导致重定向风暴；与AOF、故障无关。19.在零信任架构中，最关键的技术控制是：A.网络微分段B.多因素认证C.持续身份验证与动态授权D.流量加密答案：C解析：零信任核心“永不信任、持续验证”，动态授权是灵魂；微分段与加密是手段。20.某银行核心系统采用“单元化架构”，每个单元承担100万用户，现需上线新业务“跨境支付”，要求“任何单元故障不影响其他单元”，设计时应遵循：A.单元间共享支付通道B.支付通道也按单元垂直拆分C.使用集中式支付中台D.使用Saga模式串行调用答案：B解析：单元化要求“业务、数据、资源”自闭环，支付通道若共享则形成跨单元依赖，违背故障隔离原则。二、案例分析题（共3题，每题20分，共60分）案例一（20分）背景：某短视频平台日活1.2亿，上传视频峰值5万条/分钟。原架构：单体+MySQL+OSS。痛点：1.上传经常502；2.转码耗时高；3.推荐Feed延迟>1分钟。团队决定重构为微服务+事件驱动架构，技术选型：UploadService、TranscodeService、FeedService、AITagService，消息中间件Kafka，对象存储MinIO，缓存RedisCluster，推荐算法TensorFlowServing。问题：1.针对“上传502”设计高可用方案，要求支持断点续传、秒传、并发上传，给出架构图文字描述并说明关键机制。（6分）2.转码服务如何基于Kafka实现“削峰填谷”并保证任务不丢？（4分）3.Feed服务需保证“用户刷Feed平均延迟<200ms”，请给出缓存与存储策略，并处理冷启动问题。（5分）4.整个链路如何做到端到端可观测？列出三类Telemetry数据及对应技术选型。（5分）答案与解析：1.架构：客户端直传MinIO，使用分片MultipartUpload，最大5GB分片；上传前调用UploadService获取带过期时间的预签名URL，秒传逻辑：计算整个文件的MD5，UploadService查询MinIO是否已存在相同ETag，若存在直接返回成功；上传完成回调UploadService，写入Kafka“video.uploaded”事件，返回202避免502；UploadService多实例无状态，前置Nginx+Keepalived，支持横向扩展；MinIO采用ErasureCode8+2，双可用区部署，容忍单AZ故障。关键机制：预签名URL将流量offload到对象存储；秒传减少90%重复上传；分片失败可重试指定分片，实现断点续传。2.转码服务：消费“video.uploaded”Topic，每个转码实例最多拉取partition数为实例CPU核数，保证单实例并行度可控；转码完成发送“video.transcoded”事件，若处理失败，捕获异常并commit失败，利用Kafka重试指数退避；生产端开启幂等，Broker开启replication.factor=3，min.insync.replicas=2，确保不丢；消费组采用“手动提交+幂等写”模式，任务表唯一键防止重复。3.Feed策略：采用“写扩散”模型：用户发表视频后，FeedService收到“video.published”事件，将videoId写入其粉丝RedisZSet（key=fanId:feed，score=时间戳），ZSet长度保持500；客户端请求带lastId，FeedService用ZREVRANGEBYSCORE分页，复杂度O(log(N)+M)，平均延迟<20ms；冷启动：新用户无粉丝，直接查询“热门池”RedisList，后台定时任务将Top1000热门写扩散到新人Feed；存储：MySQL只存归档Feed，Redis失效后异步回源，保证最终一致。4.可观测：Trace：OpenTelemetry+Jaeger，采集上传→转码→Feed全链路；Metrics：Prometheus+Grafana，暴露QPS、P99延迟、Kafkalag；Logs：Loki收集容器日志，通过TraceId关联；三类数据分别解决“请求去了哪”“系统是否健康”“错误详情是什么”。案例二（20分）背景：某省级“健康码”系统高峰QPS8万，需与公安、卫健委、三大运营商、铁路、海关等外部接口对接，接口延迟50~800ms不等。原架构：单体Java+OracleRAC，高峰期线程池打满、FullGC5秒/次。省里要求“7×24可用、数据零丢失、上线窗口<30分钟”。问题：1.设计“零中断发布”流水线，要求灰度、可回滚，给出关键步骤与工具。（6分）2.外部接口慢且不稳定，如何设计“自适应熔断与降级”，需给出算法与配置参数。（5分）3.数据库层如何做到“异地双活”且RPO=0？（5分）4.给出“用户扫码亮码”接口的缓存与一致性方案，防止“红码变绿码”延迟。（4分）答案与解析：1.流水线：GitLabCI触发构建→Sonar扫描→镜像推送到Harbor；K8s集群使用ArgoRollouts，策略：canary，10%→30%→100%，每阶段自动运行健康检查（Prometheus指标：P99<500ms、错误率<1%）；若失败自动回滚到旧版本，窗口<5分钟；使用Istio进行流量镜像，将1%实时流量复制到新版本做影子测试，验证外部接口无异常。2.熔断：采用Sentinel，规则：慢调用比例>60%且RT>300ms触发降级，时间窗口10s，恢复探测3次间隔5s；自适应：基于Little’sLaw动态调整并发阈值，当等待队列>（QPS×平均RT×1.5）时拒绝；降级：返回缓存的“上次健康状态”+提示“数据延迟”，用户仍可亮码。3.异地双活：采用MySQLGroupReplication+半同步，双主写，使用GTID+冲突检测；上层通过ShardingSphere做读写拆分与分片键（用户身份证前6位路由），避免跨地事务；仲裁站点部署于第三地，防止脑裂；网络专线延迟<10ms，满足RPO=0；若异地延迟>20ms，则退化为“异地多活异步”，RPO=秒级。4.亮码缓存：采用“用户Id+颜色”缓存于Redis，TTL=30s，写操作先删缓存再更新数据库，使用分布式锁保证并发；变更事件通过BinlogCDC推送到Redis，延迟<500ms；对红码用户设置短TTL=5s，降低风险；客户端本地缓存5s，后台变更后通过WebSocket推送刷新。案例三（20分）背景：某跨国物流公司构建“数字孪生”平台，实时追踪全球100万集装箱，每10秒上报一次温湿度、位置、震动。数据量：每秒10万条、峰值30万条，单条1KB。需求：1.实时计算集装箱是否偏离路线；2.保存90天明细供审计；3.支持按箱号查询最近轨迹，延迟<1s；4.历史数据需低成本归档。问题：1.设计端到端数据流，说明采用的消息中间件、流计算引擎及存储，并给出理由。（6分）2.如何实现“偏离路线”实时告警，要求误报率<1%，给出算法与窗口设计。（5分）3.针对“按箱号查询最近轨迹”的延迟要求，给出存储模型与索引策略。（4分）4.给出冷热数据分层方案，计算存储成本对比。（5分）答案与解析：1.数据流：设备→MQTToverTLS→IoTGateway（EMQXCluster）→Kafka（Topic：logistics.raw，partition=箱号hash，保证单箱保序）；Flink消费，并行度=Kafkapartition数，使用MapState存储每箱最近路线；明细写入ClickHouse（分区按日+箱号），90天自动TTL；告警结果写入Kafka→AlertService→钉钉/Slack；归档：ClickHouse数据>90天迁移至OSS（Parquet），通过Hive外部表查询。2.偏离算法：采用“地理围栏+滑动窗口”：预计算路线Buffer200米，Flink使用5分钟Tumble窗口，统计箱号在窗口内90%坐标点落在Buffer外则触发；引入Kalman滤波平滑GPS漂移，降低误报；窗口内点数<10则跳过，防止设备离线误报；