2025年上半年軟考高級(jí)架構(gòu)師綜合考試試題及參考答案一、單項(xiàng)選擇題（每題1分，共30分。每題只有一個(gè)最符合題意的選項(xiàng)）1.某大型電商系統(tǒng)采用微服務(wù)架構(gòu)，訂單服務(wù)需要調(diào)用庫(kù)存服務(wù)扣減庫(kù)存。若庫(kù)存服務(wù)出現(xiàn)短暫不可用，架構(gòu)師最優(yōu)先應(yīng)引入哪種機(jī)制保證業(yè)務(wù)連續(xù)性？A.熔斷器模式B.事件溯源C.兩階段提交D.TCC補(bǔ)償事務(wù)答案：A解析：短暫不可用場(chǎng)景下，熔斷器可快速失敗并降級(jí)，避免級(jí)聯(lián)雪崩；TCC與2PC太重，事件溯源用于審計(jì)而非實(shí)時(shí)容錯(cuò)。2.在TOGAFADM的哪一階段會(huì)首次出現(xiàn)“架構(gòu)契約（ArchitectureContract）”？A.預(yù)備階段B.階段A：架構(gòu)愿景C.階段D：技術(shù)架構(gòu)D.階段E：機(jī)會(huì)與解決方案答案：D解析：階段E需與供應(yīng)商簽約，架構(gòu)契約作為正式法律文件首次出現(xiàn)。3.某金融核心系統(tǒng)要求RPO=0、RTO<15秒，同城雙活已部署，但異地仍需建設(shè)容災(zāi)。架構(gòu)師最合理的異地?cái)?shù)據(jù)復(fù)制策略是：A.異步復(fù)制，延遲3秒B.半同步復(fù)制，延遲100毫秒C.同步復(fù)制，延遲5毫秒D.批量夜備+日志追補(bǔ)答案：C解析：RPO=0只有同步復(fù)制滿足；異地5ms需專用光纖，成本雖高但符合監(jiān)管“極端情況零丟失”要求。4.以下關(guān)于DDD聚合根的說(shuō)法，錯(cuò)誤的是：A.聚合根負(fù)責(zé)保證業(yè)務(wù)不變量B.聚合根可引用另一聚合根實(shí)體C.聚合根內(nèi)部實(shí)體必須全局唯一D.聚合根通過(guò)資源庫(kù)完成持久化答案：C解析：聚合內(nèi)子實(shí)體只需局部唯一，由聚合根ID+子實(shí)體局部ID聯(lián)合標(biāo)識(shí)。5.某系統(tǒng)采用Kafka進(jìn)行事件驅(qū)動(dòng)，消費(fèi)端為微服務(wù)，需保證“僅且一次”語(yǔ)義。架構(gòu)師應(yīng)：A.開啟Kafka事務(wù)+冪等producer+ExactlyOnce消費(fèi)者B.關(guān)閉自動(dòng)提交，手動(dòng)提交offset，業(yè)務(wù)表與offset原子寫入C.使用RabbitMQ替代KafkaD.采用KafkaStreams的suppress操作答案：B解析：Kafka0.11+雖支持EOS，但跨系統(tǒng)場(chǎng)景下“業(yè)務(wù)庫(kù)+offset”原子寫入（DB事務(wù)包offset表）是最通用、可審計(jì)的方案。6.在IPv6過(guò)渡階段，某企業(yè)內(nèi)網(wǎng)需同時(shí)支持IPv4/IPv6雙棧，但發(fā)現(xiàn)部分老舊打印機(jī)僅支持IPv4。架構(gòu)師應(yīng)優(yōu)先部署：A.NAT64B.DNS64C.464XLATD.雙棧DHCPv6答案：A解析：NAT64允許IPv6only客戶端訪問(wèn)IPv4only服務(wù)器，打印機(jī)無(wú)需改造；464XLAT用于客戶端IPv4only場(chǎng)景，與本題相反。7.某PaaS平臺(tái)使用Kubernetes，要求多租戶網(wǎng)絡(luò)隔離且租戶可自定義IP段。最佳CNI插件組合是：A.CalicoBGP+NetworkPolicyB.FlannelVXLAN+MultusC.CiliumeBPF+CRDIPPoolD.Canal+iptables答案：C解析：Cilium的CRDIPPool允許租戶自定義CIDR，eBPF實(shí)現(xiàn)高效隔離與策略，比Calico的BGP更靈活。8.在SRE實(shí)踐中，SLI應(yīng)首選：A.服務(wù)器CPU利用率B.每請(qǐng)求延遲P99C.日志錯(cuò)誤行數(shù)D.網(wǎng)絡(luò)吞吐率答案：B解析：SLI需直接反映用戶體驗(yàn)，P99延遲是黃金指標(biāo)；CPU、吞吐為系統(tǒng)指標(biāo)，非服務(wù)層。9.某系統(tǒng)使用SpringCloudGateway，需在網(wǎng)關(guān)上實(shí)現(xiàn)基于JWT的細(xì)粒度授權(quán)（RBAC），令牌payload僅含userId。最佳擴(kuò)展點(diǎn)是：A.GlobalFilter讀取userId后調(diào)用戶中心獲取角色，再轉(zhuǎn)發(fā)下游B.自定義ReactiveAuthenticationManagerC.在TokenRelayFilter后加RateLimiterD.將角色寫回JWT并重新簽名答案：A解析：令牌瘦身原則：payload只放最小身份，角色實(shí)時(shí)查用戶中心，避免角色變更后令牌失效延遲。10.以下關(guān)于云原生12要素應(yīng)用（12factorApp）的描述，正確的是：A.日志應(yīng)寫到本地文件以便排錯(cuò)B.配置應(yīng)硬編碼在鏡像中C.進(jìn)程應(yīng)無(wú)狀態(tài)且可水平擴(kuò)展D.依賴應(yīng)通過(guò)操作系統(tǒng)包管理安裝答案：C解析：12factor明確進(jìn)程無(wú)狀態(tài)，日志事件流、配置注入環(huán)境變量、依賴顯式聲明。11.某高并發(fā)秒殺采用Redis+Lua腳本扣減庫(kù)存，為防止超賣，Lua腳本中關(guān)鍵命令序列是：A.WATCH庫(kù)存鍵；GET；DECR；EXECB.EVAL“if(redis.call('get',KEYS[1])>=ARGV[1])thenreturnredis.call('decrby',KEYS[1],ARGV[1])elsereturn1end”C.MULTI；DECR；EXECD.SETNX+EXPIRE答案：B解析：Lua腳本在Redis單線程原子執(zhí)行，無(wú)需WATCH，避免競(jìng)態(tài)；DECRBY后返回剩余庫(kù)存即可。12.在DevOps流水線中，為驗(yàn)證“基礎(chǔ)設(shè)施即代碼”的Terraform變更是否引入漂移，應(yīng)：A.terraformapplyautoapproveB.terraformplandetailedexitcodeC.terraformrefreshD.taint資源后重部署答案：B解析：plandetailedexitcode返回2表示有變更，可用于CI門禁；refresh僅同步狀態(tài)不對(duì)比。13.某銀行采用“集中式+分布式”混合核心，賬務(wù)系統(tǒng)為集中式DB2，互聯(lián)網(wǎng)支付為MySQL分庫(kù)分表。為保證跨庫(kù)事務(wù)一致性，架構(gòu)師采用：A.本地消息表+MQ最終一致B.SeataAT模式C.XA跨庫(kù)事務(wù)D.Saga編排答案：A解析：銀行核心賬務(wù)對(duì)性能要求極高，本地消息表（eBay模式）+MQ是最成熟、可審計(jì)、可回查方案；XA性能差，Seata需侵入。14.以下關(guān)于零信任架構(gòu)（NIST800207）的七大原則，錯(cuò)誤的是：A.網(wǎng)絡(luò)位置不再?zèng)Q定信任B.所有設(shè)備、用戶、服務(wù)需動(dòng)態(tài)認(rèn)證授權(quán)C.內(nèi)網(wǎng)流量默認(rèn)可信D.持續(xù)監(jiān)測(cè)與響應(yīng)答案：C解析：零信任核心即“永不信任、持續(xù)驗(yàn)證”，內(nèi)網(wǎng)流量同樣需加密與策略控制。15.某邊緣計(jì)算場(chǎng)景使用K3s，節(jié)點(diǎn)通過(guò)4G網(wǎng)絡(luò)接入，常因信號(hào)不穩(wěn)定導(dǎo)致節(jié)點(diǎn)頻繁離線。為降低kubeapiserver負(fù)載，應(yīng)：A.調(diào)大nodestatusupdatefrequencyB.啟用kubeapiserver的–watchcachesizesC.調(diào)大nodemonitorgraceperiodD.使用etcds3備份答案：C解析：graceperiod延長(zhǎng)可避免因短暫網(wǎng)絡(luò)抖動(dòng)觸發(fā)Pod驅(qū)逐；A反向操作會(huì)加重心跳。16.在領(lǐng)域建模工作坊中，識(shí)別出“訂單”、“商品”、“庫(kù)存”三個(gè)聚合，其中“訂單”與“庫(kù)存”需保證庫(kù)存扣減一致性。架構(gòu)師應(yīng)引入：A.領(lǐng)域事件“庫(kù)存已扣”由庫(kù)存聚合發(fā)布，訂單聚合訂閱B.訂單聚合直接調(diào)用庫(kù)存聚合領(lǐng)域服務(wù)C.將庫(kù)存聚合合并到訂單聚合D.應(yīng)用層事務(wù)腳本一次性扣減答案：A解析：跨聚合一致性通過(guò)領(lǐng)域事件異步解耦，符合DDD原則；合并聚合會(huì)導(dǎo)致臃腫。17.某系統(tǒng)使用Prometheus+Grafana監(jiān)控，發(fā)現(xiàn)kubelet的“container_memory_working_set_bytes”指標(biāo)持續(xù)接近limit，但Pod未OOMKilled。最可能原因是：A.節(jié)點(diǎn)內(nèi)存充足，內(nèi)核未觸發(fā)回收B.指標(biāo)采集延遲C.limit設(shè)置過(guò)大D.應(yīng)用使用swap答案：A解析：working_set接近limit僅說(shuō)明“壓力”，是否被殺由節(jié)點(diǎn)內(nèi)存水位與oom_score決定；節(jié)點(diǎn)充裕時(shí)不會(huì)立即Kill。18.在ISO/IEC25010質(zhì)量模型中，“可移植性”子特性不包括：A.適應(yīng)性B.易安裝性C.共存性D.易替換性答案：D解析：易替換性屬于“可維護(hù)性”子特性；可移植性含適應(yīng)性、易安裝、共存、可替換性（注意與易替換性區(qū)分）。19.某Serverless平臺(tái)基于Knative，冷啟動(dòng)耗時(shí)8秒，主要瓶頸在Java應(yīng)用啟動(dòng)。最有效的優(yōu)化是：A.升級(jí)Kubernetes至1.28B.使用QuarkusnativeimageC.調(diào)大initialScaleD.啟用clusterautoscaler答案：B解析：GraalVMnativeimage可將啟動(dòng)時(shí)間降至百毫秒級(jí)，直擊冷啟動(dòng)痛點(diǎn)；initialScale僅緩解并發(fā)，不解決啟動(dòng)。20.在數(shù)據(jù)治理中，為落實(shí)“數(shù)據(jù)主權(quán)”合規(guī)，歐盟GDPR要求企業(yè)支持：A.數(shù)據(jù)可攜帶權(quán)B.數(shù)據(jù)匿名化不可逆C.數(shù)據(jù)本地化存儲(chǔ)D.數(shù)據(jù)最長(zhǎng)保留期7年答案：A解析：GDPR第20條明確數(shù)據(jù)可攜帶權(quán)；本地化非強(qiáng)制，匿名化是技術(shù)手段，非權(quán)利。21.某高可用數(shù)據(jù)庫(kù)采用三節(jié)點(diǎn)Raft，Leader因GC暫停導(dǎo)致心跳超時(shí)，F(xiàn)ollower發(fā)起選舉。若網(wǎng)絡(luò)分區(qū)導(dǎo)致各節(jié)點(diǎn)無(wú)法互通，系統(tǒng)將：A.一直選不出Leader，不可用B.腦裂，出現(xiàn)雙主C.舊Leader繼續(xù)提供服務(wù)D.自動(dòng)降級(jí)為只讀答案：A解析：Raft需多數(shù)派（2/3）才能提交日志，網(wǎng)絡(luò)分區(qū)后無(wú)多數(shù)派，系統(tǒng)停寫，保證一致性。22.在C4模型中，描述“容器”圖時(shí)應(yīng)聚焦：A.用戶與系統(tǒng)交互流程B.系統(tǒng)間消息序列C.單個(gè)容器內(nèi)的類圖D.運(yùn)行時(shí)進(jìn)程/容器及其技術(shù)棧答案：D解析：C4第二層“容器圖”展示可部署單元（容器、數(shù)據(jù)庫(kù)）及其通信；類圖屬第四層。23.某系統(tǒng)使用GitLabCI，需在合并請(qǐng)求階段自動(dòng)檢測(cè)SQL注入。最佳集成方式是：A.在.gitlabci.yml中調(diào)用sqlmap掃描測(cè)試環(huán)境APIB.使用SonarQube插件+自定義規(guī)則C.在代碼合并后觸發(fā)OWASPZAPD.人工代碼評(píng)審答案：B解析：靜態(tài)分析可在MR階段提前發(fā)現(xiàn)注入漏洞，無(wú)需部署；sqlmap需運(yùn)行時(shí)代價(jià)高。24.在多云災(zāi)備場(chǎng)景，為降低跨云傳輸成本，對(duì)象存儲(chǔ)數(shù)據(jù)同步應(yīng)采用：A.跨區(qū)域復(fù)制+定時(shí)切換B.云廠商A的Snowball離線搬遷C.基于rclone的增量同步+壓縮D.雙寫模式答案：C解析：rclone支持S3API增量、壓縮、斷點(diǎn)續(xù)傳，成本最低；Snowball適合PB級(jí)一次性搬遷。25.某AI推理服務(wù)使用GPU節(jié)點(diǎn)，發(fā)現(xiàn)顯存占用逐步上升，最終OOM。最可能泄露源是：A.TensorFlow2.x默認(rèn)eager模式未顯式釋放圖B.CUDAdriver版本不匹配C.kubelet未開啟DevicePluginD.節(jié)點(diǎn)未安裝nvidiadocker答案：A解析：eager模式下循環(huán)創(chuàng)建圖未釋放導(dǎo)致顯存泄露；需用tf.function或顯式清空。26.在ISO27001認(rèn)證過(guò)程中，SOA指：A.適用性聲明B.安全操作手冊(cè)C.風(fēng)險(xiǎn)評(píng)估報(bào)告D.審計(jì)記錄答案：A解析：StatementofApplicability，描述控制措施選擇與排除理由，是認(rèn)證核心文檔。27.某系統(tǒng)采用藍(lán)綠發(fā)布，切換瞬間出現(xiàn)502錯(cuò)誤，持續(xù)5秒后恢復(fù)。最可能缺失：A.健康檢查預(yù)熱B.數(shù)據(jù)庫(kù)連接池重連C.灰度流量比例D.容器鏡像拉取答案：A解析：藍(lán)綠切換時(shí)新環(huán)境JVM冷啟動(dòng)，連接池、緩存未預(yù)熱，需Readiness探針+小流量預(yù)熱。28.在響應(yīng)式編程中，背壓（Backpressure）策略不包括：A.DROPB.LATESTC.BUFFERD.BLOCK答案：D解析：Reactor三種策略：DROP、LATEST、BUFFER；BLOCK非背壓策略，為阻塞調(diào)用。29.某邊緣網(wǎng)關(guān)使用MQTT5.0，需支持“請(qǐng)求響應(yīng)”模式，應(yīng)使用：A.RETAIN標(biāo)志B.TopicAliasC.CorrelationData+ResponseTopicD.WillMessage答案：C解析：MQTT5.0新增CorrelationData與ResponseTopic，實(shí)現(xiàn)異步RPC。30.在FinOps成本優(yōu)化中，為降低EC2閑置浪費(fèi)，應(yīng)優(yōu)先采用：A.SavingsPlanB.Spot實(shí)例C.自動(dòng)停機(jī)調(diào)度+ResourceTaggingD.預(yù)留實(shí)例答案：C解析：自動(dòng)停機(jī)（基于標(biāo)簽）直接消除閑置，ROI最快；Savings/RI需承諾用量，Spot不適合常駐。二、案例分析題（共5題，每題10分，共50分）案例一（10分）某城商行新一代核心系統(tǒng)采用“單元化+分片”架構(gòu)，每單元承擔(dān)千萬(wàn)級(jí)賬戶，單元內(nèi)使用MySQLGroupReplication（MGR）三節(jié)點(diǎn)，跨單元使用分布式事務(wù)消息。上線前壓測(cè)發(fā)現(xiàn)：當(dāng)MGR單節(jié)點(diǎn)網(wǎng)絡(luò)抖動(dòng)5秒即觸發(fā)重新選主，TPS下降90%，且出現(xiàn)大量“Lockwaittimeout”異常。請(qǐng)分析根因并給出三條例行性改進(jìn)措施。答案與解析：根因：1.MGR單主模式下，寫操作全部路由到Primary，重新選主期間寫中斷；2.業(yè)務(wù)連接池未感知主切換，仍向舊主發(fā)送事務(wù)，導(dǎo)致鎖等待；3.選主超時(shí)參數(shù)group_replication_member_expel_timeout默認(rèn)0，立即驅(qū)逐，無(wú)緩沖。改進(jìn)：1.調(diào)大expel_timeout=15s，允許短暫抖動(dòng)自愈；2.連接池集成MySQL8.0的“dnssrv”與“readwritesplitting”，自動(dòng)感知主切換；3.業(yè)務(wù)側(cè)減少長(zhǎng)事務(wù)，拆分為基于消息的最終一致，降低鎖粒度。案例二（10分）某視頻直播平臺(tái)峰值QPS200萬(wàn)，采用CDN+源站結(jié)構(gòu)。源站使用Nginx+Lua緩存TS分片到內(nèi)存，但頻繁出現(xiàn)502。監(jiān)控發(fā)現(xiàn)源站upstream_response_time突增，CPUidle70%，無(wú)FullGC，網(wǎng)卡未丟包。請(qǐng)給出診斷思路與優(yōu)化方案。答案與解析：診斷：1.觀察Nginxerrorlog，發(fā)現(xiàn)“upstreamprematurelyclosedconnection”；2.使用sss查看TCPalloc，發(fā)現(xiàn)timewait60萬(wàn)，源端口耗盡；3.確認(rèn)Lua腳本使用短連接回源存儲(chǔ)（OSS），每次請(qǐng)求新建TCP。優(yōu)化：1.在Lua中引入tcp連接池（resty.redis或resty.http），復(fù)用連接；2.內(nèi)核參數(shù)net.ipv4.ip_local_port_range擴(kuò)至3276860999；3.開啟OSS的HTTPSkeepalive，減少TLS握手；4.CDN層增加Range緩存，降低回源率30%。案例三（10分）某IoT車聯(lián)網(wǎng)平臺(tái)需支持百萬(wàn)級(jí)車輛并發(fā)上傳CAN總線數(shù)據(jù)，消息體約500字節(jié)，峰值帶寬5Gbps。現(xiàn)有架構(gòu)：MQTToverTLS→Kafka→Flink→HDFS。實(shí)際運(yùn)行出現(xiàn)Kafkabroker頻繁ISR抖動(dòng)，單分區(qū)lag堆積千萬(wàn)。請(qǐng)給出擴(kuò)容與調(diào)優(yōu)方案。答案與解析：1.計(jì)算吞吐：500B2M=1GB/s≈8Gbps，已超單機(jī)房上行，需按地區(qū)邊緣MQTT集群就近接入；2.將單topic200分區(qū)擴(kuò)至800，并按vehicleIdhash，避免熱分區(qū)；3.調(diào)優(yōu)：linger.ms=50，batch.size=512KB，compression.type=lz4，降低網(wǎng)絡(luò)IO40%；4.使用KafkaTieredStorageoffload冷數(shù)據(jù)，減少磁盤隨機(jī)讀；5.Flink并行度與Kafka分區(qū)一一對(duì)應(yīng)，開啟checkpointalignedtimeout=30s，避免背壓導(dǎo)致ISR抖動(dòng)。案例四（10分）某政務(wù)云采用私有云+公有云混合部署，監(jiān)管要求“三同步”：同步規(guī)劃、同步建設(shè)、同步運(yùn)行。架構(gòu)師需設(shè)計(jì)一套跨云安全合規(guī)方案，包含網(wǎng)絡(luò)、數(shù)據(jù)、運(yùn)維三方面要點(diǎn)，請(qǐng)列出關(guān)鍵措施。答案與解析：網(wǎng)絡(luò)：1.采用IPSec+VXLAN打通跨云加密隧道，啟用PKI雙向證書認(rèn)證；2.內(nèi)網(wǎng)DNS拆分視圖，敏感域名僅在私域解析，防止DNS劫持。數(shù)據(jù)：1.跨云同步使用國(guó)密SM4/SM9全鏈路加密，對(duì)象存儲(chǔ)啟用KMS自有密鑰（BYOK）；2.建立數(shù)據(jù)分級(jí)分類，IV級(jí)以上數(shù)據(jù)禁止出境，使用數(shù)據(jù)脫敏+Token化。運(yùn)維：1.統(tǒng)一身份云（IDaaS）+多因子，審計(jì)