2025年云計(jì)算云服務(wù)可伸縮性試題及答案一、單項(xiàng)選擇題（每題2分，共20分）1.以下關(guān)于云服務(wù)可伸縮性的描述中，錯(cuò)誤的是（）A.水平擴(kuò)展（ScaleOut）通過(guò)增加實(shí)例數(shù)量提升容量B.垂直擴(kuò)展（ScaleUp）受限于單實(shí)例硬件上限C.自動(dòng)伸縮（AutoScaling）僅依賴CPU使用率作為觸發(fā)指標(biāo)D.無(wú)服務(wù)器架構(gòu)（Serverless）的伸縮由云平臺(tái)完全管理2.在Kubernetes集群中，用于實(shí)現(xiàn)Pod水平自動(dòng)伸縮的控制器是（）A.DeploymentB.StatefulSetC.HorizontalPodAutoscaler（HPA）D.VerticalPodAutoscaler（VPA）3.某電商平臺(tái)大促期間流量峰值為日常的10倍，最適合的數(shù)據(jù)庫(kù)伸縮策略是（）A.單主庫(kù)垂直升級(jí)至更高配置B.主從復(fù)制+讀寫分離+分片集群C.僅使用緩存數(shù)據(jù)庫(kù)替代關(guān)系型數(shù)據(jù)庫(kù)D.關(guān)閉部分非核心業(yè)務(wù)數(shù)據(jù)庫(kù)實(shí)例4.以下哪項(xiàng)不是無(wú)服務(wù)器函數(shù)（如AWSLambda）伸縮的局限性？（）A.冷啟動(dòng)延遲（ColdStart）B.單實(shí)例執(zhí)行時(shí)長(zhǎng)限制C.自動(dòng)擴(kuò)縮容完全由云廠商控制D.無(wú)法處理突發(fā)高頻請(qǐng)求5.云負(fù)載均衡器（LoadBalancer）在可伸縮性中的核心作用是（）A.監(jiān)控后端實(shí)例健康狀態(tài)B.將請(qǐng)求均勻分發(fā)至多個(gè)實(shí)例C.限制單個(gè)實(shí)例的最大請(qǐng)求數(shù)D.記錄請(qǐng)求日志用于審計(jì)6.某企業(yè)采用容器化部署，發(fā)現(xiàn)高峰時(shí)段Pod頻繁因內(nèi)存不足被OOMKiller終止，最可能的優(yōu)化措施是（）A.增加Pod的CPU請(qǐng)求（Requests）B.調(diào)整Pod的內(nèi)存限制（Limits）并啟用垂直自動(dòng)伸縮C.減少Pod副本數(shù)以降低資源競(jìng)爭(zhēng)D.更換為更大規(guī)格的虛擬機(jī)實(shí)例7.以下關(guān)于彈性計(jì)算（ElasticCompute）的描述，正確的是（）A.彈性計(jì)算僅支持按需付費(fèi)模式B.彈性伸縮的響應(yīng)時(shí)間與云平臺(tái)的調(diào)度能力無(wú)關(guān)C.混合云場(chǎng)景中需通過(guò)API網(wǎng)關(guān)統(tǒng)一管理跨云資源伸縮D.突發(fā)性能實(shí)例（BurstableInstances）無(wú)法應(yīng)對(duì)持續(xù)高負(fù)載8.某系統(tǒng)的自動(dòng)伸縮策略設(shè)置為“當(dāng)CPU使用率超過(guò)70%時(shí)增加1個(gè)實(shí)例，低于30%時(shí)減少1個(gè)實(shí)例”，可能導(dǎo)致的問(wèn)題是（）A.實(shí)例數(shù)量波動(dòng)頻繁（Flapping）B.峰值流量時(shí)實(shí)例擴(kuò)容不足C.低負(fù)載時(shí)實(shí)例無(wú)法完全釋放D.無(wú)法觸發(fā)縮容操作9.容器編排工具（如Kubernetes）中，用于定義Pod在節(jié)點(diǎn)間分布規(guī)則的是（）A.PodDisruptionBudget（PDB）B.Affinity/Anti-Affinity規(guī)則C.ResourceQuotaD.LimitRange10.無(wú)服務(wù)器架構(gòu)（Serverless）實(shí)現(xiàn)“無(wú)限伸縮”的關(guān)鍵依賴是（）A.云平臺(tái)的資源池化與動(dòng)態(tài)分配能力B.用戶自定義的擴(kuò)縮容策略C.固定數(shù)量的預(yù)啟動(dòng)實(shí)例D.與傳統(tǒng)虛擬機(jī)相同的資源隔離機(jī)制二、填空題（每空2分，共20分）1.云服務(wù)可伸縮性的核心目標(biāo)是通過(guò)__________或__________資源，匹配動(dòng)態(tài)變化的工作負(fù)載需求。2.自動(dòng)伸縮的三要素是__________、__________和__________。3.Kubernetes中，__________用于調(diào)整Pod的垂直資源（CPU/內(nèi)存）分配，__________用于定義Pod不可用的最大數(shù)量以保證服務(wù)穩(wěn)定性。4.數(shù)據(jù)庫(kù)水平分片（Sharding）的常見(jiàn)策略包括__________分片和__________分片（如按用戶ID或時(shí)間范圍）。5.無(wú)服務(wù)器函數(shù)的冷啟動(dòng)時(shí)間通常受__________、__________和運(yùn)行時(shí)環(huán)境復(fù)雜度影響。三、簡(jiǎn)答題（每題8分，共40分）1.簡(jiǎn)述水平擴(kuò)展（ScaleOut）與垂直擴(kuò)展（ScaleUp）的優(yōu)缺點(diǎn)，并說(shuō)明二者適用場(chǎng)景。2.說(shuō)明云平臺(tái)自動(dòng)伸縮（AutoScaling）的觸發(fā)指標(biāo)類型（至少列舉4種），并舉例說(shuō)明自定義指標(biāo)的應(yīng)用場(chǎng)景。3.對(duì)比Kubernetes的HPA（HorizontalPodAutoscaler）與CA（ClusterAutoscaler）的功能差異，說(shuō)明二者如何協(xié)同工作。4.無(wú)服務(wù)器架構(gòu)（Serverless）宣稱“自動(dòng)無(wú)限伸縮”，但實(shí)際應(yīng)用中可能存在哪些限制？請(qǐng)至少列舉3點(diǎn)并解釋原因。5.某企業(yè)云系統(tǒng)在流量突增時(shí)出現(xiàn)“彈性不足”（無(wú)法及時(shí)擴(kuò)容），請(qǐng)從監(jiān)控、調(diào)度、資源池三個(gè)層面分析可能的原因。四、案例分析題（20分）某電商平臺(tái)計(jì)劃在2025年“雙11”大促期間應(yīng)對(duì)峰值流量（預(yù)計(jì)為日常的15倍，持續(xù)2小時(shí)），其核心業(yè)務(wù)架構(gòu)包括：-Web應(yīng)用層：基于容器化的微服務(wù)（Kubernetes集群）-數(shù)據(jù)層：MySQL主從集群（主庫(kù)寫入，從庫(kù)讀?。?Redis緩存-接入層：云負(fù)載均衡器（ALB）+Nginx反向代理當(dāng)前問(wèn)題：歷史大促中曾出現(xiàn)以下故障：（1）Web應(yīng)用層在流量峰值前30分鐘擴(kuò)容緩慢，部分Pod因資源不足無(wú)法啟動(dòng)；（2）MySQL主庫(kù)寫入壓力過(guò)大，出現(xiàn)慢查詢和連接超時(shí)；（3）Redis緩存命中率下降，部分熱點(diǎn)數(shù)據(jù)未被有效緩存。請(qǐng)?jiān)O(shè)計(jì)一套可伸縮性優(yōu)化方案，要求涵蓋以下內(nèi)容：（1）Web應(yīng)用層的自動(dòng)伸縮策略優(yōu)化（包括HPA配置、資源請(qǐng)求/限制調(diào)整、集群擴(kuò)展機(jī)制）；（2）數(shù)據(jù)層的伸縮與性能優(yōu)化（MySQL和Redis的具體措施）；（3）接入層的流量分發(fā)與緩沖機(jī)制優(yōu)化；（4）監(jiān)控與故障熔斷的補(bǔ)充方案。云計(jì)算云服務(wù)可伸縮性試題答案一、單項(xiàng)選擇題1.C（自動(dòng)伸縮可基于CPU、內(nèi)存、QPS、延遲等多種指標(biāo)觸發(fā)）2.C（HPA負(fù)責(zé)水平伸縮Pod副本數(shù)）3.B（分片集群可通過(guò)水平擴(kuò)展提升讀寫能力）4.D（無(wú)服務(wù)器可處理高頻請(qǐng)求，冷啟動(dòng)是主要限制）5.B（負(fù)載均衡的核心是分發(fā)請(qǐng)求以利用多實(shí)例）6.B（垂直伸縮調(diào)整內(nèi)存限制，VPA可自動(dòng)優(yōu)化資源）7.D（突發(fā)實(shí)例僅能短時(shí)間高負(fù)載，持續(xù)需調(diào)整實(shí)例類型）8.A（閾值間隔過(guò)小易導(dǎo)致實(shí)例頻繁增減）9.B（Affinity規(guī)則定義Pod分布策略）10.A（云平臺(tái)資源池化是無(wú)限伸縮的基礎(chǔ)）二、填空題1.動(dòng)態(tài)擴(kuò)展；收縮2.監(jiān)控指標(biāo)；伸縮策略；執(zhí)行動(dòng)作3.VPA（VerticalPodAutoscaler）；PodDisruptionBudget（PDB）4.范圍（Range）；哈希（Hash）5.函數(shù)包大??；依賴庫(kù)數(shù)量三、簡(jiǎn)答題1.水平擴(kuò)展與垂直擴(kuò)展對(duì)比-水平擴(kuò)展（ScaleOut）：增加實(shí)例數(shù)量（如新增服務(wù)器/容器）。優(yōu)點(diǎn)：無(wú)單實(shí)例性能上限，成本靈活（按需擴(kuò)容），高可用性（實(shí)例間冗余）；缺點(diǎn)：分布式系統(tǒng)復(fù)雜度高（網(wǎng)絡(luò)通信、數(shù)據(jù)一致性），需改造應(yīng)用支持無(wú)狀態(tài)。適用場(chǎng)景：無(wú)狀態(tài)應(yīng)用（如Web服務(wù)器、API網(wǎng)關(guān)）、流量可線性拆分的負(fù)載。-垂直擴(kuò)展（ScaleUp）：提升單實(shí)例性能（如升級(jí)CPU/內(nèi)存）。優(yōu)點(diǎn)：架構(gòu)改動(dòng)小（無(wú)需調(diào)整應(yīng)用），適合有狀態(tài)應(yīng)用（如數(shù)據(jù)庫(kù)主節(jié)點(diǎn)）；缺點(diǎn)：受硬件上限限制（單實(shí)例最大配置），成本隨配置指數(shù)增長(zhǎng)（高規(guī)格實(shí)例單價(jià)更高）。適用場(chǎng)景：有狀態(tài)核心組件（如數(shù)據(jù)庫(kù)主庫(kù)）、難以拆分的單實(shí)例應(yīng)用（如大型計(jì)算任務(wù)）。2.自動(dòng)伸縮觸發(fā)指標(biāo)類型-系統(tǒng)指標(biāo)：CPU使用率、內(nèi)存使用率、網(wǎng)絡(luò)吞吐量（如出/入帶寬）、磁盤IOPS。-應(yīng)用指標(biāo)：QPS（每秒請(qǐng)求數(shù)）、請(qǐng)求延遲（如P99延遲）、錯(cuò)誤率（如5xx錯(cuò)誤占比）。-自定義指標(biāo)：通過(guò)云監(jiān)控（如AWSCloudWatch、阿里云ARMS）上報(bào)的業(yè)務(wù)指標(biāo)，例如購(gòu)物車添加次數(shù)、支付成功量。-外部指標(biāo)：第三方系統(tǒng)數(shù)據(jù)（如天氣API預(yù)測(cè)的用戶訪問(wèn)量）。示例：某直播平臺(tái)可將“當(dāng)前在線人數(shù)”作為自定義指標(biāo)，當(dāng)在線人數(shù)超過(guò)100萬(wàn)時(shí)觸發(fā)擴(kuò)容，確保直播推流服務(wù)的穩(wěn)定性。3.HPA與CA的協(xié)同-HPA（HorizontalPodAutoscaler）：基于指標(biāo)調(diào)整Pod副本數(shù)（如CPU>70%時(shí)增加Pod），但僅在現(xiàn)有節(jié)點(diǎn)資源足夠時(shí)生效。若節(jié)點(diǎn)資源不足（如所有節(jié)點(diǎn)CPU已用滿），HPA無(wú)法創(chuàng)建新Pod。-CA（ClusterAutoscaler）：監(jiān)控集群中未調(diào)度的Pod（Pending狀態(tài)），自動(dòng)擴(kuò)展或收縮節(jié)點(diǎn)數(shù)量（如新增EC2實(shí)例或刪除空閑節(jié)點(diǎn)），確保有足夠資源運(yùn)行HPA創(chuàng)建的Pod。協(xié)同流程：流量增加→HPA檢測(cè)到指標(biāo)超標(biāo)→嘗試創(chuàng)建更多Pod→若節(jié)點(diǎn)資源不足→CA檢測(cè)到PendingPod→啟動(dòng)新節(jié)點(diǎn)→HPA創(chuàng)建的Pod調(diào)度到新節(jié)點(diǎn)→流量下降→HPA減少Pod→CA刪除空閑節(jié)點(diǎn)。4.無(wú)服務(wù)器伸縮的限制-冷啟動(dòng)延遲：函數(shù)首次調(diào)用或長(zhǎng)時(shí)間未使用后，需啟動(dòng)運(yùn)行時(shí)環(huán)境（下載代碼、初始化依賴），導(dǎo)致請(qǐng)求延遲（通常100ms~數(shù)秒）。原因：云平臺(tái)為節(jié)省資源，未預(yù)啟動(dòng)所有實(shí)例。-執(zhí)行時(shí)長(zhǎng)限制：?jiǎn)魏瘮?shù)實(shí)例最大運(yùn)行時(shí)間（如AWSLambda為15分鐘），無(wú)法處理長(zhǎng)任務(wù)（如大文件轉(zhuǎn)碼）。原因：無(wú)服務(wù)器設(shè)計(jì)為短時(shí)間任務(wù)，長(zhǎng)任務(wù)需拆分或使用其他服務(wù)（如EC2）。-資源上限限制：?jiǎn)蝹€(gè)賬戶的函數(shù)并發(fā)數(shù)限制（如AWS默認(rèn)1000并發(fā)），超量需申請(qǐng)?zhí)犷~。原因：云平臺(tái)需全局資源管理，避免單個(gè)用戶占用過(guò)多資源。-狀態(tài)管理困難：函數(shù)實(shí)例無(wú)持久化存儲(chǔ)（臨時(shí)存儲(chǔ)僅存活于函數(shù)執(zhí)行期間），需依賴外部存儲(chǔ)（如S3、Redis），增加系統(tǒng)復(fù)雜度。5.彈性不足的三層原因分析-監(jiān)控層面：指標(biāo)采集延遲（如云監(jiān)控每60秒采集一次，無(wú)法捕捉秒級(jí)流量突增）；指標(biāo)選擇不合理（僅用CPU而忽略內(nèi)存或網(wǎng)絡(luò)）；未設(shè)置多維度告警（如同時(shí)監(jiān)控QPS和延遲）。-調(diào)度層面：伸縮策略滯后（如擴(kuò)容需等待5分鐘評(píng)估指標(biāo)，而流量1分鐘內(nèi)翻倍）；資源預(yù)留不足（如節(jié)點(diǎn)啟動(dòng)需10分鐘，未預(yù)啟動(dòng)部分實(shí)例）；跨可用區(qū)調(diào)度失?。ㄈ缒晨捎脜^(qū)資源池已滿，無(wú)法創(chuàng)建新節(jié)點(diǎn)）。-資源池層面：云平臺(tái)區(qū)域資源池容量不足（如大促期間大量用戶同時(shí)擴(kuò)容，導(dǎo)致實(shí)例庫(kù)存緊張）；預(yù)留實(shí)例類型單一（僅使用按需實(shí)例，未混合使用Spot實(shí)例或預(yù)留實(shí)例）；容器鏡像拉取緩慢（鏡像過(guò)大，節(jié)點(diǎn)啟動(dòng)后需長(zhǎng)時(shí)間下載鏡像才能運(yùn)行Pod）。四、案例分析題優(yōu)化方案設(shè)計(jì)1.Web應(yīng)用層自動(dòng)伸縮策略優(yōu)化-HPA配置：-指標(biāo)選擇：同時(shí)監(jiān)控CPU使用率（目標(biāo)80%）、內(nèi)存使用率（目標(biāo)75%）、自定義指標(biāo)（Nginx的QPS，目標(biāo)5000次/秒）。-伸縮步長(zhǎng)：設(shè)置“擴(kuò)容時(shí)每次增加30%副本數(shù)（最小2，最大50）”，避免緩慢擴(kuò)容；縮容時(shí)“冷卻時(shí)間15分鐘”，防止頻繁縮容。-指標(biāo)采集頻率：通過(guò)Prometheus+kube-state-metrics實(shí)現(xiàn)秒級(jí)指標(biāo)采集（原云監(jiān)控60秒→5秒），提升響應(yīng)速度。-資源請(qǐng)求/限制調(diào)整：-為關(guān)鍵微服務(wù)（如訂單服務(wù)）設(shè)置“Requests=CPU1核，Memory2Gi”，“Limits=CPU2核，Memory4Gi”，避免因資源不足被OOMKiller終止。-非關(guān)鍵服務(wù)（如日志服務(wù)）設(shè)置“Requests=CPU0.5核，Memory1Gi”，允許超賣資源，提升集群資源利用率。-集群擴(kuò)展機(jī)制：-啟用KubernetesClusterAutoscaler（CA），設(shè)置節(jié)點(diǎn)擴(kuò)容策略：“當(dāng)集群資源利用率（CPU/內(nèi)存）>85%時(shí)，30秒內(nèi)啟動(dòng)新節(jié)點(diǎn)（EC2m6g.large）”；縮容時(shí)“節(jié)點(diǎn)連續(xù)空閑30分鐘且無(wú)Pod運(yùn)行時(shí)，終止節(jié)點(diǎn)”。-預(yù)啟動(dòng)3個(gè)備用節(jié)點(diǎn)（使用Spot實(shí)例降低成本），大促前2小時(shí)激活，縮短節(jié)點(diǎn)啟動(dòng)時(shí)間（原需10分鐘→2分鐘可用）。2.數(shù)據(jù)層伸縮與性能優(yōu)化-MySQL優(yōu)化：-主庫(kù)垂直擴(kuò)展+水平分片：將主庫(kù)從db.t3.xlarge升級(jí)至db.r6g.2xlarge（更高內(nèi)存和網(wǎng)絡(luò)性能）；按用戶ID哈希分片（16個(gè)分片），每個(gè)分片獨(dú)立主從（主庫(kù)寫入，2個(gè)從庫(kù)讀?。?，減輕單主庫(kù)壓力。-連接池優(yōu)化：使用ProxySQL作為中間件，限制單分片最大連接數(shù)（500），避免連接風(fēng)暴；開(kāi)啟連接復(fù)用（連接存活時(shí)間300秒），減少握手開(kāi)銷。-慢查詢治理：大促前通過(guò)pt-query-digest分析歷史慢查詢，為高頻查詢添加索引（如訂單表的user_id+create_time聯(lián)合索引）；禁用自動(dòng)更新統(tǒng)計(jì)信息（大促期間只讀）。-Redis優(yōu)化：-集群化部署：將單實(shí)例Redis升級(jí)為Cluster模式（6節(jié)點(diǎn)，3主3從），按哈希槽分片，提升寫入和讀取吞吐量（原5萬(wàn)QPS→20萬(wàn)QPS）。-熱點(diǎn)數(shù)據(jù)預(yù)加載：大促前通過(guò)Lua腳本將爆款商品庫(kù)存、價(jià)格等數(shù)據(jù)預(yù)寫入Redis，并設(shè)置“永不過(guò)期+后臺(tái)異步刷新”，避免緩存擊穿。-內(nèi)存策略調(diào)整：?jiǎn)⒂谩癮llkeys-lru”淘汰策略，設(shè)置內(nèi)存閾值為總?cè)萘康?0%，觸發(fā)時(shí)淘汰最久未使用的鍵；開(kāi)啟持久化（RDB每小時(shí)+AOF每秒），但大促期間暫停AOF（避免磁盤IO影響性能）。3.接入層流量分發(fā)與緩沖機(jī)制優(yōu)化-云負(fù)載均衡器（ALB）：-開(kāi)啟“會(huì)話粘性”（基于Cookie，有效期5分鐘），減少跨實(shí)例會(huì)話同步開(kāi)銷；-設(shè)置“請(qǐng)求限流”（單IP每秒100次），防止惡意攻擊；-啟用“跨可用區(qū)負(fù)載均衡”，將流量分發(fā)至3個(gè)可用區(qū)的節(jié)點(diǎn)，避免單區(qū)故障。-Nginx反向代理：-配置“請(qǐng)求緩沖”（client_body_buffer_size16k;proxy_