2025年云计算云服务可伸缩性试题及答案

2025年云计算云服务可伸缩性试题及答案一、单项选择题（每题2分，共20分）1.以下关于云服务可伸缩性的描述中，错误的是（）A.水平扩展（ScaleOut）通过增加实例数量提升容量B.垂直扩展（ScaleUp）受限于单实例硬件上限C.自动伸缩（AutoScaling）仅依赖CPU使用率作为触发指标D.无服务器架构（Serverless）的伸缩由云平台完全管理2.在Kubernetes集群中，用于实现Pod水平自动伸缩的控制器是（）A.DeploymentB.StatefulSetC.HorizontalPodAutoscaler（HPA）D.VerticalPodAutoscaler（VPA）3.某电商平台大促期间流量峰值为日常的10倍，最适合的数据库伸缩策略是（）A.单主库垂直升级至更高配置B.主从复制+读写分离+分片集群C.仅使用缓存数据库替代关系型数据库D.关闭部分非核心业务数据库实例4.以下哪项不是无服务器函数（如AWSLambda）伸缩的局限性？（）A.冷启动延迟（ColdStart）B.单实例执行时长限制C.自动扩缩容完全由云厂商控制D.无法处理突发高频请求5.云负载均衡器（LoadBalancer）在可伸缩性中的核心作用是（）A.监控后端实例健康状态B.将请求均匀分发至多个实例C.限制单个实例的最大请求数D.记录请求日志用于审计6.某企业采用容器化部署，发现高峰时段Pod频繁因内存不足被OOMKiller终止，最可能的优化措施是（）A.增加Pod的CPU请求（Requests）B.调整Pod的内存限制（Limits）并启用垂直自动伸缩C.减少Pod副本数以降低资源竞争D.更换为更大规格的虚拟机实例7.以下关于弹性计算（ElasticCompute）的描述，正确的是（）A.弹性计算仅支持按需付费模式B.弹性伸缩的响应时间与云平台的调度能力无关C.混合云场景中需通过API网关统一管理跨云资源伸缩D.突发性能实例（BurstableInstances）无法应对持续高负载8.某系统的自动伸缩策略设置为“当CPU使用率超过70%时增加1个实例，低于30%时减少1个实例”，可能导致的问题是（）A.实例数量波动频繁（Flapping）B.峰值流量时实例扩容不足C.低负载时实例无法完全释放D.无法触发缩容操作9.容器编排工具（如Kubernetes）中，用于定义Pod在节点间分布规则的是（）A.PodDisruptionBudget（PDB）B.Affinity/Anti-Affinity规则C.ResourceQuotaD.LimitRange10.无服务器架构（Serverless）实现“无限伸缩”的关键依赖是（）A.云平台的资源池化与动态分配能力B.用户自定义的扩缩容策略C.固定数量的预启动实例D.与传统虚拟机相同的资源隔离机制二、填空题（每空2分，共20分）1.云服务可伸缩性的核心目标是通过__________或__________资源，匹配动态变化的工作负载需求。2.自动伸缩的三要素是__________、__________和__________。3.Kubernetes中，__________用于调整Pod的垂直资源（CPU/内存）分配，__________用于定义Pod不可用的最大数量以保证服务稳定性。4.数据库水平分片（Sharding）的常见策略包括__________分片和__________分片（如按用户ID或时间范围）。5.无服务器函数的冷启动时间通常受__________、__________和运行时环境复杂度影响。三、简答题（每题8分，共40分）1.简述水平扩展（ScaleOut）与垂直扩展（ScaleUp）的优缺点，并说明二者适用场景。2.说明云平台自动伸缩（AutoScaling）的触发指标类型（至少列举4种），并举例说明自定义指标的应用场景。3.对比Kubernetes的HPA（HorizontalPodAutoscaler）与CA（ClusterAutoscaler）的功能差异，说明二者如何协同工作。4.无服务器架构（Serverless）宣称“自动无限伸缩”，但实际应用中可能存在哪些限制？请至少列举3点并解释原因。5.某企业云系统在流量突增时出现“弹性不足”（无法及时扩容），请从监控、调度、资源池三个层面分析可能的原因。四、案例分析题（20分）某电商平台计划在2025年“双11”大促期间应对峰值流量（预计为日常的15倍，持续2小时），其核心业务架构包括：-Web应用层：基于容器化的微服务（Kubernetes集群）-数据层：MySQL主从集群（主库写入，从库读取）+Redis缓存-接入层：云负载均衡器（ALB）+Nginx反向代理当前问题：历史大促中曾出现以下故障：（1）Web应用层在流量峰值前30分钟扩容缓慢，部分Pod因资源不足无法启动；（2）MySQL主库写入压力过大，出现慢查询和连接超时；（3）Redis缓存命中率下降，部分热点数据未被有效缓存。请设计一套可伸缩性优化方案，要求涵盖以下内容：（1）Web应用层的自动伸缩策略优化（包括HPA配置、资源请求/限制调整、集群扩展机制）；（2）数据层的伸缩与性能优化（MySQL和Redis的具体措施）；（3）接入层的流量分发与缓冲机制优化；（4）监控与故障熔断的补充方案。云计算云服务可伸缩性试题答案一、单项选择题1.C（自动伸缩可基于CPU、内存、QPS、延迟等多种指标触发）2.C（HPA负责水平伸缩Pod副本数）3.B（分片集群可通过水平扩展提升读写能力）4.D（无服务器可处理高频请求，冷启动是主要限制）5.B（负载均衡的核心是分发请求以利用多实例）6.B（垂直伸缩调整内存限制，VPA可自动优化资源）7.D（突发实例仅能短时间高负载，持续需调整实例类型）8.A（阈值间隔过小易导致实例频繁增减）9.B（Affinity规则定义Pod分布策略）10.A（云平台资源池化是无限伸缩的基础）二、填空题1.动态扩展；收缩2.监控指标；伸缩策略；执行动作3.VPA（VerticalPodAutoscaler）；PodDisruptionBudget（PDB）4.范围（Range）；哈希（Hash）5.函数包大小；依赖库数量三、简答题1.水平扩展与垂直扩展对比-水平扩展（ScaleOut）：增加实例数量（如新增服务器/容器）。优点：无单实例性能上限，成本灵活（按需扩容），高可用性（实例间冗余）；缺点：分布式系统复杂度高（网络通信、数据一致性），需改造应用支持无状态。适用场景：无状态应用（如Web服务器、API网关）、流量可线性拆分的负载。-垂直扩展（ScaleUp）：提升单实例性能（如升级CPU/内存）。优点：架构改动小（无需调整应用），适合有状态应用（如数据库主节点）；缺点：受硬件上限限制（单实例最大配置），成本随配置指数增长（高规格实例单价更高）。适用场景：有状态核心组件（如数据库主库）、难以拆分的单实例应用（如大型计算任务）。2.自动伸缩触发指标类型-系统指标：CPU使用率、内存使用率、网络吞吐量（如出/入带宽）、磁盘IOPS。-应用指标：QPS（每秒请求数）、请求延迟（如P99延迟）、错误率（如5xx错误占比）。-自定义指标：通过云监控（如AWSCloudWatch、阿里云ARMS）上报的业务指标，例如购物车添加次数、支付成功量。-外部指标：第三方系统数据（如天气API预测的用户访问量）。示例：某直播平台可将“当前在线人数”作为自定义指标，当在线人数超过100万时触发扩容，确保直播推流服务的稳定性。3.HPA与CA的协同-HPA（HorizontalPodAutoscaler）：基于指标调整Pod副本数（如CPU>70%时增加Pod），但仅在现有节点资源足够时生效。若节点资源不足（如所有节点CPU已用满），HPA无法创建新Pod。-CA（ClusterAutoscaler）：监控集群中未调度的Pod（Pending状态），自动扩展或收缩节点数量（如新增EC2实例或删除空闲节点），确保有足够资源运行HPA创建的Pod。协同流程：流量增加→HPA检测到指标超标→尝试创建更多Pod→若节点资源不足→CA检测到PendingPod→启动新节点→HPA创建的Pod调度到新节点→流量下降→HPA减少Pod→CA删除空闲节点。4.无服务器伸缩的限制-冷启动延迟：函数首次调用或长时间未使用后，需启动运行时环境（下载代码、初始化依赖），导致请求延迟（通常100ms~数秒）。原因：云平台为节省资源，未预启动所有实例。-执行时长限制：单函数实例最大运行时间（如AWSLambda为15分钟），无法处理长任务（如大文件转码）。原因：无服务器设计为短时间任务，长任务需拆分或使用其他服务（如EC2）。-资源上限限制：单个账户的函数并发数限制（如AWS默认1000并发），超量需申请提额。原因：云平台需全局资源管理，避免单个用户占用过多资源。-状态管理困难：函数实例无持久化存储（临时存储仅存活于函数执行期间），需依赖外部存储（如S3、Redis），增加系统复杂度。5.弹性不足的三层原因分析-监控层面：指标采集延迟（如云监控每60秒采集一次，无法捕捉秒级流量突增）；指标选择不合理（仅用CPU而忽略内存或网络）；未设置多维度告警（如同时监控QPS和延迟）。-调度层面：伸缩策略滞后（如扩容需等待5分钟评估指标，而流量1分钟内翻倍）；资源预留不足（如节点启动需10分钟，未预启动部分实例）；跨可用区调度失败（如某可用区资源池已满，无法创建新节点）。-资源池层面：云平台区域资源池容量不足（如大促期间大量用户同时扩容，导致实例库存紧张）；预留实例类型单一（仅使用按需实例，未混合使用Spot实例或预留实例）；容器镜像拉取缓慢（镜像过大，节点启动后需长时间下载镜像才能运行Pod）。四、案例分析题优化方案设计1.Web应用层自动伸缩策略优化-HPA配置：-指标选择：同时监控CPU使用率（目标80%）、内存使用率（目标75%）、自定义指标（Nginx的QPS，目标5000次/秒）。-伸缩步长：设置“扩容时每次增加30%副本数（最小2，最大50）”，避免缓慢扩容；缩容时“冷却时间15分钟”，防止频繁缩容。-指标采集频率：通过Prometheus+kube-state-metrics实现秒级指标采集（原云监控60秒→5秒），提升响应速度。-资源请求/限制调整：-为关键微服务（如订单服务）设置“Requests=CPU1核，Memory2Gi”，“Limits=CPU2核，Memory4Gi”，避免因资源不足被OOMKiller终止。-非关键服务（如日志服务）设置“Requests=CPU0.5核，Memory1Gi”，允许超卖资源，提升集群资源利用率。-集群扩展机制：-启用KubernetesClusterAutoscaler（CA），设置节点扩容策略：“当集群资源利用率（CPU/内存）>85%时，30秒内启动新节点（EC2m6g.large）”；缩容时“节点连续空闲30分钟且无Pod运行时，终止节点”。-预启动3个备用节点（使用Spot实例降低成本），大促前2小时激活，缩短节点启动时间（原需10分钟→2分钟可用）。2.数据层伸缩与性能优化-MySQL优化：-主库垂直扩展+水平分片：将主库从db.t3.xlarge升级至db.r6g.2xlarge（更高内存和网络性能）；按用户ID哈希分片（16个分片），每个分片独立主从（主库写入，2个从库读取），减轻单主库压力。-连接池优化：使用ProxySQL作为中间件，限制单分片最大连接数（500），避免连接风暴；开启连接复用（连接存活时间300秒），减少握手开销。-慢查询治理：大促前通过pt-query-digest分析历史慢查询，为高频查询添加索引（如订单表的user_id+create_time联合索引）；禁用自动更新统计信息（大促期间只读）。-Redis优化：-集群化部署：将单实例Redis升级为Cluster模式（6节点，3主3从），按哈希槽分片，提升写入和读取吞吐量（原5万QPS→20万QPS）。-热点数据预加载：大促前通过Lua脚本将爆款商品库存、价格等数据预写入Redis，并设置“永不过期+后台异步刷新”，避免缓存击穿。-内存策略调整：启用“allkeys-lru”淘汰策略，设置内存阈值为总容量的80%，触发时淘汰最久未使用的键；开启持久化（RDB每小时+AOF每秒），但大促期间暂停AOF（避免磁盘IO影响性能）。3.接入层流量分发与缓冲机制优化-云负载均衡器（ALB）：-开启“会话粘性”（基于Cookie，有效期5分钟），减少跨实例会话同步开销；-设置“请求限流”（单IP每秒100次），防止恶意攻击；-启用“跨可用区负载均衡”，将流量分发至3个可用区的节点，避免单区故障。-Nginx反向代理：-配置“请求缓冲”（client_body_buffer_size16k;proxy_