2025年度計算機軟考考試[系統(tǒng)架構(gòu)設(shè)計師]復(fù)習題及答案一、單項選擇題（每題2分，共20分）1.以下關(guān)于軟件架構(gòu)風格的描述中，錯誤的是（）。A.管道-過濾器風格適合需要數(shù)據(jù)處理流水線的場景（如編譯器）B.事件驅(qū)動風格通過事件隊列解耦組件，支持異步通信C.分層風格中，高層組件可直接調(diào)用任意低層組件以提高效率D.客戶-服務(wù)器風格通過明確的職責劃分實現(xiàn)資源集中管理答案：C解析：分層風格要求組件只能訪問相鄰或更底層的組件，避免跨層調(diào)用導致的耦合增加和可維護性下降。2.某電商系統(tǒng)需要支持“大促期間10萬QPS的商品查詢”，其核心質(zhì)量屬性是（）。A.可用性B.性能C.安全性D.可修改性答案：B解析：QPS（每秒查詢數(shù)）直接反映系統(tǒng)處理請求的能力，屬于性能屬性中的吞吐量指標。3.設(shè)計模式中，（）模式通過定義接口讓類的實例化延遲到子類，解決了框架與具體實現(xiàn)的解耦問題。A.工廠方法B.抽象工廠C.策略D.觀察者答案：A解析：工廠方法模式（FactoryMethod）的核心是定義一個創(chuàng)建對象的接口，由子類決定實例化哪個類，符合“延遲實例化”的描述。4.分布式系統(tǒng)中，CAP定理指的是（）三者不可兼得。A.一致性、可用性、分區(qū)容忍性B.一致性、原子性、分區(qū)容忍性C.正確性、可用性、持久性D.完整性、原子性、持久性答案：A解析：CAP定理由EricBrewer提出，指出分布式系統(tǒng)無法同時滿足一致性（Consistency）、可用性（Availability）和分區(qū)容忍性（PartitionTolerance）。5.云原生架構(gòu)中，（）技術(shù)通過容器化封裝應(yīng)用，結(jié)合編排工具實現(xiàn)自動化部署與擴縮容。A.ServerlessB.微服務(wù)C.KubernetesD.服務(wù)網(wǎng)格答案：C解析：Kubernetes（K8s）是云原生領(lǐng)域主流的容器編排工具，負責容器的調(diào)度、部署、擴縮容及容錯管理。6.軟件需求分析中，（）方法通過用戶故事（UserStory）描述功能需求，強調(diào)用戶價值與場景。A.結(jié)構(gòu)化分析B.面向?qū)ο蠓治鯟.敏捷需求D.形式化需求答案：C解析：敏捷開發(fā)中的用戶故事（如“作為買家，我需要查看訂單詳情，以便跟蹤物流”）是典型的敏捷需求描述方式，注重用戶場景與優(yōu)先級。7.架構(gòu)評估方法ATAM（架構(gòu)權(quán)衡分析方法）的核心步驟不包括（）。A.場景收集與分析B.架構(gòu)描述C.風險評估D.代碼靜態(tài)分析答案：D解析：ATAM的步驟包括場景收集、架構(gòu)描述、需求驗證、風險評估等，代碼靜態(tài)分析屬于詳細設(shè)計或測試階段的活動。8.數(shù)據(jù)庫設(shè)計中，為解決高并發(fā)寫操作下的性能瓶頸，通常采用（）策略。A.讀寫分離B.垂直分庫C.水平分片D.數(shù)據(jù)庫緩存答案：C解析：水平分片（Sharding）將同一表的數(shù)據(jù)按規(guī)則（如用戶ID哈希）分散到多個數(shù)據(jù)庫，直接減少單庫的寫壓力，適用于高并發(fā)寫場景。9.以下關(guān)于安全架構(gòu)設(shè)計的描述，正確的是（）。A.敏感數(shù)據(jù)存儲時應(yīng)使用對稱加密（如AES）而非哈希（如SHA-256）B.OAuth2.0的授權(quán)碼模式（AuthorizationCode）比隱式模式（Implicit）更安全C.為簡化管理，所有微服務(wù)應(yīng)共享同一個API網(wǎng)關(guān)進行認證D.零信任架構(gòu)（ZeroTrust）的核心是“默認信任內(nèi)部網(wǎng)絡(luò)”答案：B解析：OAuth2.0的授權(quán)碼模式通過服務(wù)器端交換令牌，避免客戶端直接處理密鑰，比隱式模式（令牌直接返回客戶端）更安全。10.實時數(shù)據(jù)流處理系統(tǒng)（如ApacheFlink）的關(guān)鍵設(shè)計目標是（）。A.支持大規(guī)模批處理B.保證低延遲與精確一次（Exactly-Once）處理C.提供強一致性事務(wù)D.簡化數(shù)據(jù)倉庫集成答案：B解析：實時流處理的核心是低延遲（毫秒級）和數(shù)據(jù)處理的準確性（如Exactly-Once語義），區(qū)別于批處理的高吞吐量。二、簡答題（每題10分，共50分）1.簡述軟件架構(gòu)設(shè)計中“質(zhì)量屬性場景”的構(gòu)成要素，并舉例說明。答案：質(zhì)量屬性場景由刺激源（StimulusSource）、刺激（Stimulus）、環(huán)境（Environment）、制品（Artifact）、響應(yīng)（Response）、響應(yīng)度量（ResponseMeasure）六要素構(gòu)成。例如：“大促期間（環(huán)境），10萬用戶（刺激源）同時發(fā)起商品詳情頁請求（刺激），商品服務(wù)（制品）需在200ms內(nèi)（響應(yīng)度量）返回完整數(shù)據(jù)（響應(yīng)）”。2.對比微服務(wù)架構(gòu)與單體架構(gòu)的優(yōu)缺點，說明微服務(wù)適用的典型場景。答案：單體架構(gòu)優(yōu)點：開發(fā)簡單、部署統(tǒng)一、調(diào)試方便；缺點：耦合度高、擴展困難、技術(shù)棧鎖定。微服務(wù)優(yōu)點：高內(nèi)聚低耦合、獨立部署、技術(shù)異構(gòu)支持；缺點：分布式復(fù)雜性（網(wǎng)絡(luò)延遲、事務(wù)）、運維成本高。適用場景：業(yè)務(wù)快速迭代（如電商促銷功能獨立發(fā)布）、需要技術(shù)異構(gòu)（如部分服務(wù)用Go，部分用Java）、高可用性要求（單個服務(wù)故障不影響整體）。3.說明分布式系統(tǒng)中“最終一致性”的實現(xiàn)方式，并列舉兩種常見協(xié)議。答案：最終一致性允許數(shù)據(jù)在短時間內(nèi)不一致，但經(jīng)過一段時間后達到一致。實現(xiàn)方式包括：異步消息隊列（如Kafka）保證操作順序，版本向量（VersionVector）解決沖突，Gossip協(xié)議傳播更新。常見協(xié)議：Amazon的Dynamo（基于向量時鐘）、Google的Spanner（TrueTime時鐘同步）。4.云原生架構(gòu)中，服務(wù)網(wǎng)格（ServiceMesh）解決了哪些問題？核心組件有哪些？答案：服務(wù)網(wǎng)格解決了微服務(wù)間通信的復(fù)雜性（如服務(wù)發(fā)現(xiàn)、負載均衡、認證、監(jiān)控），將這些功能從業(yè)務(wù)代碼中解耦，通過Sidecar代理（如Envoy）實現(xiàn)。核心組件包括數(shù)據(jù)平面（Sidecar代理處理流量）和控制平面（如Istio的Pilot負責策略分發(fā)、Mixer負責遙測）。5.簡述軟件需求規(guī)格說明書（SRS）的主要內(nèi)容，并說明如何驗證其質(zhì)量。答案：SRS內(nèi)容包括：引言（目的、范圍）、總體描述（運行環(huán)境、設(shè)計約束）、功能需求（用例、接口）、非功能需求（性能、安全）、外部接口（硬件、軟件）、數(shù)據(jù)需求（數(shù)據(jù)模型、數(shù)據(jù)流）。質(zhì)量驗證方法：需求評審（stakeholders參與）、需求跟蹤（確?？勺匪荩⒃万炞C（通過用戶測試確認合理性）、形式化驗證（如用Z語言檢查邏輯一致性）。三、案例分析題（每題25分，共50分）案例1：某公司計劃開發(fā)“直播電商平臺”，需支持百萬級并發(fā)觀看、實時彈幕、秒級訂單支付，同時要求用戶信息泄露風險低于0.01%。請設(shè)計其核心架構(gòu)，并回答以下問題：（1）畫出邏輯架構(gòu)圖（用文字描述關(guān)鍵組件），說明各組件的職責。（2）針對高并發(fā)觀看場景，提出3項性能優(yōu)化策略。（3）設(shè)計用戶信息安全防護方案，涵蓋存儲、傳輸、訪問控制環(huán)節(jié)。答案：（1）邏輯架構(gòu)關(guān)鍵組件：-接入層：CDN（緩存靜態(tài)資源如直播流、封面圖）、負載均衡（如Nginx，按地域分流）；-業(yè)務(wù)層：直播服務(wù)（推流、轉(zhuǎn)碼）、彈幕服務(wù)（使用RedisPub/Sub實現(xiàn)實時消息）、訂單服務(wù)（微服務(wù)化，拆分庫存、支付子服務(wù)）；-數(shù)據(jù)層：分布式數(shù)據(jù)庫（TiDB，支持高并發(fā)寫）、緩存（Redis，存儲熱門商品信息）、消息隊列（RocketMQ，削峰填谷訂單請求）；-支撐層：服務(wù)網(wǎng)格（Istio，管理微服務(wù)通信）、監(jiān)控（Prometheus+Grafana，實時監(jiān)控QPS、延遲）、安全中心（WAF，防SQL注入；密鑰管理系統(tǒng)，存儲用戶密碼哈希）。（2）高并發(fā)性能優(yōu)化策略：①直播流采用HLS/RTMP協(xié)議分塊傳輸，CDN邊緣節(jié)點緩存，減少源站壓力；②彈幕服務(wù)使用內(nèi)存數(shù)據(jù)庫（Redis）存儲實時消息，異步寫入數(shù)據(jù)庫（降低IO延遲）；③訂單服務(wù)采用“削峰填谷”：大促前預(yù)熱緩存（加載熱門商品庫存），訂單請求先入消息隊列（RocketMQ），由消費者按閾值處理（如每秒10萬單）。（3）用戶信息安全方案：存儲環(huán)節(jié)：用戶密碼采用BCrypt哈希+鹽值存儲，敏感信息（如身份證號）使用國密SM4加密，密鑰由硬件安全模塊（HSM）管理；傳輸環(huán)節(jié)：所有接口強制HTTPS（TLS1.3），API網(wǎng)關(guān)驗證客戶端證書（雙向SSL）；訪問控制：采用RBAC模型（角色如普通用戶、主播、管理員），微服務(wù)間調(diào)用通過JWT令牌鑒權(quán)（令牌含用戶ID、角色，5分鐘過期），關(guān)鍵操作（如修改支付密碼）需二次驗證（短信驗證碼）。案例2：某企業(yè)擬構(gòu)建“AI推薦系統(tǒng)”，需基于用戶行為（點擊、購買）、商品屬性（類別、價格）、實時場景（時間、地域）提供個性化推薦。要求推薦延遲≤100ms，模型更新周期≤1天，支持A/B測試。請設(shè)計其技術(shù)架構(gòu)，并回答：（1）推薦系統(tǒng)的分層架構(gòu)設(shè)計（數(shù)據(jù)層、計算層、服務(wù)層）。（2）實時特征計算的技術(shù)選型（如框架、存儲）及原因。（3）如何實現(xiàn)模型的在線更新與A/B測試？答案：（1）分層架構(gòu)：-數(shù)據(jù)層：實時數(shù)據(jù)（用戶點擊行為，通過Kafka采集）、離線數(shù)據(jù)（歷史購買記錄，存儲于Hive）、元數(shù)據(jù)（商品屬性，MySQL）；-計算層：離線特征工程（Spark，提供用戶畫像、商品標簽）、實時特征計算（Flink，處理Kafka流數(shù)據(jù)，計算“最近1小時點擊次數(shù)”等實時特征）、模型訓練（TensorFlow/PyTorch，定期從HDFS讀取特征數(shù)據(jù)訓練）；-服務(wù)層：推薦服務(wù)（SpringBoot微服務(wù)，加載模型文件，結(jié)合實時特征提供推薦結(jié)果）、A/B測試平臺（分流用戶，控制不同模型的流量比例）、監(jiān)控服務(wù)（記錄推薦點擊率、轉(zhuǎn)化率）。（2）實時特征計算技術(shù)選型：框架選擇ApacheFlink，原因：支持毫秒級低延遲處理，提供Exactly-Once語義保證特征準確性；存儲選擇Redis，原因：內(nèi)存數(shù)據(jù)庫支持高并發(fā)讀?。ㄍ扑]服務(wù)需快速獲取用戶實時特征），設(shè)置TTL（如1天）自動清理過期