简介《刘鹏云计算第三版》配套习题答案以docx文档形式呈现适合正在学习云计算课程、准备期末考试或考研复习的高校学生与自学者使用。文档按章节梳理了教材中的核心知识与对应习题解答内容涵盖云计算的服务模型IaaS、PaaS、SaaS、部署模式公有云、私有云、混合云、社区云以及虚拟化、分布式存储、安全机制等架构设计要点并对企业应用和个人应用等典型场景展开分析同时介绍了安全挑战与应对策略。资源包共1个文件格式为docx文档压缩包大小9.51MB便于直接打开阅读或打印。目前已有1700人学习下载反馈较为实用。借助这份答案读者可以快速核对习题思路、查漏补缺加深对云计算关键概念的理解适合作为教材学习的辅助资料。1. 云计算习题答案里最反直觉的一点资源池化不是「共享」而是「重新发明硬件」如果只用一个概念解释云计算为什么能按需付费大多数人的答案是「虚拟化」。但虚拟化只是手段真正的机制是「资源池化」——它把一台物理机变成一面可以随时插拔的插孔墙把存储变成一个能即时切出、回收、计费的逻辑卷。这份云计算的第三版习题答案里最容易被跳过的知识点恰好是理解整个云平台架构的钥匙。题库反复追问的 IaaS、PaaS、SaaS 边界、跨机房容灾、安全模型全都可以从「资源如何被抽象、切分、计费」这条主线推导出来。搞懂资源池化大多数判断题和简答题不用死背拿着场景直接推结论就行。2. 虚拟化从物理机到逻辑资源的本质转换靠的是「一层谎言」2.1 三种虚拟化区分的是「特权指令谁来处理」全虚拟化、半虚拟化和硬件辅助习题答案里出现频率最高的辨析题就是说出全虚拟化、半虚拟化、硬件辅助虚拟化的区别。很多人背完定义就放下了考试时换个问法立刻翻车。其实这三个词不是三档性能排名而是「处理特权指令的三种策略」。理解 x86 的特权级别就全通了Ring 0 是操作系统内核的地盘Ring 3 属于用户程序而要跑虚拟机客户机内核必须假装自己还在 Ring 0。装一个 VMM虚拟机监视器夹在中间它把客户机的敏感指令截下来自己冒充硬件完成操作。全虚拟化的最短路径是二进制翻译客户机内核不认识 VMMVMM 就动态扫描敏感指令把它们替换成对自己的调用。半虚拟化反过来让客户机内核明确知道自己跑在虚拟机上主动把敏感操作封装成 hypercall 交给 hypervisor。硬件辅助虚拟化是 CPU 厂商动手改架构Intel 的 VMX、AMD 的 SVM 让「进虚拟机、执行、被动退出」变成硬件级的 VMXON、VMRUN 指令。这一切的本质是让客户机活在 VMM 编织的谎言里它以为自己在控制硬件实际每次碰硬件都要向 VMM 报备。while (true) { // VM exitGuest 触发敏感指令、访问受限内存或收到外部中断 save_guest_registers(guest_context); reason vm_exit_reason(); // 拿到退出原因码 switch (reason) { case EXIT_EPT_VIOLATION: // 内存访问踩到虚拟映射之外 handle_ept_violation(); break; case EXIT_MSR_WRITE: // Guest 想写模型专属寄存器 validate_and_forward(guest_context); break; case EXIT_HLT: // Guest 执行 HLT 想睡一会儿 schedule_next_vcpu(); // 趁机切换给别的 vCPU break; } vmenter(guest_context); // 重新进入 Guest恢复现场 }这段循环就是 VMM 的全部人生捕获、裁决、重新进入。每次循环都是一次上下文切换CPU 的时间被这种切换反复吃掉。习题里常考的「CPU 超卖」本质是多个 vCPU 映射到同一个物理核心VMM 凭这个循环把时间片轮流分给不同的客户机。超卖比不是越高越好因为客户机之间的抢跑会让 VM exit 频率飙升物理 CPU 大量时间耗在 VMM 自己身上业务反而变慢。习题答案里那句「超卖过多导致性能雪崩」指的就是这个调度循环的过热。2.2 内存虚拟化的两层地址翻译影子页表到 EPT 的演化内存虚拟化的核心矛盾是客户机以为自己管理的是物理内存其实那只是宿主机地址空间里一块被划出来的区域。如果让客户机的页表直接操作宿主的物理地址客户机就能越界访问别人的内存。早期解决套路是影子页表VMM 维护一张从「客户机虚拟地址」直接映射到「宿主机物理地址」的影子页表客户机每次改页表VMM 都要重新同步。这个方案的代价很重缺页处理要走两层TLB 不断失效同步开销也大。硬件辅助的出现把两个映射拆开了客户机维护第一层 GVA 到 GPAVMM 维护第二层 GPA 到 HPACPU 通过 EPTIntel或 NPTAMD在一次地址翻译里完成两级换算。影子页表的时代里热迁移要把内存页和大量元数据一起搬到目标机到了 EPT 时代内存映射关系天然可分块导出热迁移就变成「预拷贝 脏页收敛 短暂停机切换」的流水线。习题常问为什么现代云主机能实现秒级热迁移答案的根就在内存虚拟化结构的变化上。2.3 I/O 虚拟化的三元矛盾性能、共享与隔离网络这块习题答案讲得少但场景题总在考。早期 I/O 虚拟化是纯软件模拟Guest 发一个网络包先陷入 VMM再让 VMM 操作真实网卡。一条数据路径经过「虚拟机陷阱、VMM 处理、真实驱动、再返回」延迟高得离谱。后来的硬件直通把物理网卡整个交给一个虚拟机性能接近裸机但别的虚拟机再也用不到这张卡共享彻底没了。SR-IOV 是中间路线物理网卡虚拟出多个 PF 和 VF每个虚拟机拿一个 VF数据路径直接进硬件VMM 只在初始化时介入。习题答案里的核心套路是性能越高共享越差强隔离必然带来额外调度开销。这个三元矛盾会一直回响在后面所有架构选择里。3. 分布式存储为什么「先复制再确认」比「写成功」更可靠3.1 三副本的写入路径与「先写日志再落盘」题目里常问「云存储如何保证数据不丢」。如果你以为答案是「多存几份」那就只看到了表面。真正关键的是写入顺序客户端把写请求发给主副本主副本首先把操作写入日志WAL日志落盘之后才去改内存数据同时把这次修改并行推给两个从副本。从副本各自写自己的日志写完回复确认。主副本收到多数确认后才给客户端返回成功。为什么非要「先写日志再落盘」因为掉电和宕机永远在措手不及的时候发生。如果先改数据再写日志崩溃后磁盘上的数据可能是半新的而日志按顺序追加天然幂等恢复时从日志尾部重放就能回到一致状态。习题答案里「副本数 3」不是拍脑袋它是可靠性和成本的一个平衡点三副本多数派确认只需要两份成功能容忍一个节点宕机同时存储成本只翻两倍而不是翻三倍第三个副本是冗余不参与多数派。3.2 一致性哈希数据分布为什么必须容忍节点变动分布式存储最容易踩的坑是用取模做数据分布server hash(key) % N。这个方案在节点数稳定时很干净但云环境里扩容、缩容、宕机换机器是日常。N 一变化几乎所有 key 都会重新映射到别的节点数据迁移量接近 100%集群直接瘫痪。一致性哈希的动机就是解决这个问题把哈希值空间看成一个环节点映射到环上数据多找顺时针遇到的第一个节点。节点增减只影响它前驱那一小段弧上的数据。class ConsistentHashRing: def __init__(self, nodes, vnodes150): self.ring {} for node in nodes: for i in range(vnodes): # 每个物理节点虚拟出 150 个虚拟节点均匀铺到环上 key sha1(f{node}:{i}.encode()).digest() self.ring[key] node self.sorted_keys sorted(self.ring.keys()) def find_node(self, key): h sha1(key.encode()).digest() for ring_key in self.sorted_keys: if ring_key h: return self.ring[ring_key] return self.ring[self.sorted_keys[0]] # 兜底到环首节点这段代码里 vnodes150 是节点加权均匀分布的关键。机器数量少时每台机器在环上只有一个点数据分布会严重偏斜某几台机器吃掉一半流量。引入大量虚拟节点相当于把每台物理机拆成一群小分身撒到环上分布就均匀了。习题里「为什么一致性哈希要配虚拟节点」的标准答案根源就是解决小规模集群热点。但一致性哈希也不是银弹。增删节点时环上局部弧段的数据要迁移如果单点数据量巨大迁移过程可能拉长到分钟级。所以现在的大型存储系统普遍叠加了分区策略数据先按 key 范围或哈希拆成固定分片再用分片作为迁移的最小单位配合后台限速把迁移变成日常静默操作。习题不会考到这层但写架构设计题时能提一句「分片 一致性哈希」直接拉开差距。3.3 资源调度从「一台装得下」到「一秒把任务铺开」虚拟化解决单机内部资源切分调度器解决平台上成千上万个容器往哪放。换个角度理解调度器是一个装箱机器人CPU、内存、磁盘、网络带宽是不同维度的箱子尺寸。最简单的调度策略是「先到先得」 哪个机器剩余容量够就往哪扔但这种「够」是伪装的——只看某个维度会造成短板浪费。比如一台机器内存吃紧但 CPU 空转新任务缺内存进不来CPU 继续闲着。常见的调度实现走的是分组贪心路线先把集群按机架或区域分组避免任务全挤在同一个故障域组内再用「最佳适配」把任务塞进剩余空间最小的节点提高整体装箱密度。云厂商倾向高密度装箱因为多塞一个实例就意味着多一份收入但密度越高突发流量把节点打爆的概率也越高。习题答案里那句「资源预留与超卖的比例需要权衡」落到底层就是在赌所有租户同时跑满的概率和你敢把超卖比调到多少是两个数字的对赌。4. IaaS、PaaS、SaaS服务模型的边界为什么越来越模糊4.1 三种模型不是三个盒子而是「责任转移」的三档刻度习题里最经典的简答题就是默写 IaaS、PaaS、SaaS 的定义和区别。背得出来不代表答得对因为真题爱考场景判断「一个团队想用云平台跑数据库但又不想碰操作系统补丁应该选哪种」这时候只背定义的人会犹豫理解责任模型的人直接画图。从下往上看整个软件栈物理硬件、虚拟机、操作系统、中间件、运行时、应用代码、数据。IaaS 负责最底下三层客户从操作系统开始自理PaaS 把中间件和运行时也接管客户只剩应用和数据SaaS 连应用都包了客户只管数据和配置。判断归属的标准不是「这个产品听起来像什么」而是「出问题的时候责任边界划在哪里」。责任项IaaSPaaSSaaS物理设备服务商服务商服务商操作系统与补丁客户服务商服务商中间件与运行时客户服务商服务商应用部署与升级客户客户服务商数据与访问控制客户客户客户这张表的真正用途不是背而是用来回答「常见问答」一道题问某种合规要求应该由谁负责时就看它落在哪一行。网络安全、物理隔离这些属于服务商兜底应用层漏洞、账号权限失窃客户怎么甩都甩不掉。习题答案里反复强调的「共享责任模型」翻译过来就是这个表格——责任不是交给云就消失了而是按层切分每一层都有一个明确的主人。4.2 容器与 Serverless 如何打穿模型边界传统分类在容器和 Serverless 面前已经不够用了。一个容器镜像里打包了运行时和应用但容器跑在你自己管理的虚拟机上它就是 IaaS 的玩法内核、网络插件都得自己操心。容器跑在托管编排平台上自动伸缩、负载均衡、滚动升级全是平台在做体验上已经是 PaaS。Serverless 更极端代码提交后平台负责一切弹性冷启动、扩容、缩容全在毫秒级完成计费粒度从「一台虚拟机按小时」变成「一次函数调用按毫秒」。习题里的判断题「Serverless 属于 PaaS」就是典型的伪命题。Serverless 的计费单元、隔离方式、部署模型和传统 PaaS 都不同它更接近一种新的抽象层级——按函数而不是按进程来组织计算。这正是为什么新版的习题答案和教材会把 Serverless 作为独立概念拿出来讲而不是硬塞进旧的三个盒子。做架构题时如果你能把「服务模型正在从分层走向光谱」这个观点写进去阅卷人一眼就能看出你不是在背题。4.3 按需计费的计量机制为什么「空转」也要钱习题里有一类计算题让人费解虚拟机开了但一直空闲为什么账单还在涨答案不在计费系统在虚拟化本身。一台虚拟机被创建后内存页表已经建立IP 地址已被分配磁盘镜像已经落盘CPU 虽然闲逛但这对资源仍被独占别人用不了。云计算的计费本质是「资源占用费」而不是「计算执行费」存储按容量计、网络按带宽计、虚拟机按生命周期计——占用即收费和是否真正计算无关。# IaaS 方式的部署从裸虚拟到可用服务每一步都要自己来 provisioner create --machine web-01 --image ubuntu install_nginx web-01 upload_app --target web-01 --path /opt/app ssh web-01 systemctl start myapp这段命令演示了 IaaS 的日常你拥有机器的全部控制权也因此承担从系统补丁到进程守护的全部运维。换到 PaaS 上同样的动作压缩成一句「提交代码平台接管剩余动作」。计费差异也很直观——IaaS 按机器规格和时长计费PaaS 按资源用量和应用实例数计费SaaS 则直接按用户数或调用量收钱。习题里的「成本计算题」考的从来不是乘法表而是你能不能选中正确的计费维度。选错维度算出来的成本可能差一个数量级。5. 避坑指南云平台习题之外的真实故障排查现场5.1 现象虚拟机一迁移服务 IP 全乱某次演示环境一台数据库虚拟机从老宿主机热迁移到新宿主机迁移报告显示成功但业务方立刻报错应用连不上数据库日志里全是 connection refused。查到最后发现迁移前后虚拟机 IP 变了数据库连接的配置还是旧地址应用侧也没有自动重连的逻辑。原因不复杂虚拟化只保证磁盘和内存状态搬过去不保证网络地址不变。跨网段迁移时原 IP 所在子网已经不属于新宿主机网络直接断了就算同网段迁移客户端的 TCP 长连接也已失效需要重新建连。解决思路是提前给入口加浮动 IP 或负载均衡器。数据库前面挂一个 VIP迁移发生时只把 VIP 的绑定关系切到新虚拟机应用连接地址完全不用动。另外数据库连接串里要配置多地址故障转移避免单点依赖。从那以后我养成的习惯是任何虚拟机上线前先问自己一句——如果它明天被调度器搬走我的应用还能不能自动连上5.2 现象三副本集群同一份数据两个节点读到不同值某次压测一个分布式存储集群读多写少压测脚本报了大量读不一致的错。同一个 key前一次请求读到新值后一次居然读到旧值。原因在于三副本确认写成功时只保证了主副本和其中一个从副本有新值另一个从副本可能还停在旧版本。后续读请求如果落到那个落后副本就会读到旧数据。这就是习题里「最终一致性」的日常一致是最终的结果过程中的短暂不一致是设计上允许的代价。解决路径有两条。业务对一致性敏感读请求带强一致参数强制走主副本或要求多数副本确认后才返回。业务能容忍旧数据就在客户端做版本号校验旧版本直接丢弃并重读。最怕的是既没带参数又没做校验把最终一致性当成强一致性用故障来的时候全团队一脸懵。多副本存储的参数文档里那一排默认值每一个都对应一种你会忘记讲的语义。5.3 现象I/O 压测结果差一个数量级测完才发现是磁盘镜像在作怪同样型号的云主机本地压测顺序读能跑满千兆网卡换个环境同样的脚本只剩十分之一的吞吐。这种「玄学」翻车大多出在虚拟磁盘的底层格式上。早期镜像默认用稀疏格式写时分配文件系统每写一个新块存储后端都要做一次「分配新块并复制」的额外操作COW。读请求也要先查映射层I/O 路径比裸设备多走几步。压测工具的随机写模式正好放大这种开销。解决思路分两层对性能敏感的数据盘用预分配的裸设备格式提前把空间一次性划好绕开写时分配对系统盘保留镜像格式的便捷性但把缓存策略调成直写或回写避免每次 I/O 都穿透到后端存储。当年压测数据一直提不上去时我一度怀疑是网络问题最后才发现是镜像格式的配置差异。从那以后每次做基准测试我都要先确认数据盘的格式、分配策略和后端存储类型再开始跑数据否则测出来的数字只能用来安慰自己。5.4 现象CPU 占用率 100%任务却在原地打转一台云主机监控显示 CPU 持续打满登录进去看进程列表业务进程还活着但任务队列没有任何进展。这就不是容量不够而是某个线程陷入自旋等待——它占着 CPU反复检查一个永远等不到的条件。常见诱因有两个一个是死锁两个线程互相握着对方需要的锁另一个是 I/O 等待被异常吞掉线程以为盘还没回实际上请求早就失败了。排查路径第一站不是 top而是看线程 dump哪个线程在等锁、等什么锁、锁被谁持有。多数情况下答案就藏在两个线程的等待关系里。对付这种问题最好的办法是提前给关键业务加上看门狗超时任务超过阈值就强制报错而不是无限等下去。习题答案里很少讲这个过程但真实运维里这种「假死」比直接宕机更难对付——它让你误以为只是负载高。6. 部署模式的取舍公有云、私有云、混合云本质是「信任边界画在哪」6.1 从「谁的硬件」到「谁的边界」习题要求默写四种部署模式的定义公有云、私有云、混合云、社区云。定义好背但真正的考题是「给你一个场景选哪种」。选错的人往往盯着「成本」和「安全」两个词但这两个词过于粗糙更准确的分类维度是信任与控制的边界。部署模式信任边界核心矛盾典型场景公有云数据与运行都由服务商兜底弹性好但不能完全掌控边界弹性测试、中小规模业务私有云硬件、网络、系统全部自建自管控制力最强但成本和运维压力高强监管数据、核心生产系统混合云敏感数据留在私有侧弹性部分借用公网资源两套环境的一致性、网络互通突发扩容、容灾切换社区云边界由多个成员组织的协议共同划定治理规则复杂、责任难分特定行业内共享基础设施理解公有云和私有云的最短路径是前者把信任交给服务商后者把信任交给自己的运维团队。混合云是两者的谈判结果——哪些数据必须留在自己的墙内哪些工作负载可以放进公共环境边界不是按功能切而是按合规要求、延迟敏感度、成本预算三个维度一起画。做过一次混合云架构设计就会感受到最难的不是技术而是边界管理两边的身份体系要不要打通网络打通后安全策略怎么统一容灾切换时流量怎么牵引。这些问题没有标准答案只能按业务一条条过。我自己的习惯是拿到一个新系统先画一张责任表格把「数据、计算、网络、安全、运维」逐项标出该由哪一方负责再谈用哪种部署模式。这张表画完部署模式自然就浮现了。习题答案教的是概念但真正留在我工作流里的是这个画表动作先划责任再选模式最后才是写代码。希望帮到你。本文还有配套的精品资源点击获取