简介：《刘鹏云计算第三版习题答案》面向学习云计算课程、准备考试或需要核对课后练习的高校学生与自学者，围绕教材第三版习题提供参考答案，便于梳理知识框架、辨析核心概念和考前查漏补缺。内容覆盖云计算基础知识、IaaS/PaaS/SaaS服务模型、公有云/私有云/混合云/社区云部署模式，以及架构设计中的虚拟化、分布式存储、平台技术与安全机制，并延伸到企业应用、个人应用、公共服务和云安全策略等章节要点，可配合教材逐章练习、整理笔记，并对服务模型差异、部署模式选择与安全策略等易混点进行对照理解。资源包内含1个docx文档，压缩后约9.51MB，目录结构便于按章节查阅。已有1700人学习下载，适合作为课程复习、作业讲评和习题校对的参考材料。

1. 先画地图：一份云计算习题答案集到底该按什么顺序复习

翻开这份云计算教材第三版的习题答案集，多数人的第一反应是从第一题顺着背到最后一题。真按这个顺序走一遍就会发现，题与题之间并不是并列关系：前面那道“什么是云计算”和后面那道“如何设计云计算架构”，其实是同一条链路的两端，中间还夹着服务模型、部署模式、虚拟化、安全这些互相衔接的模块。更省力的做法是先画地图：概念底座（五大特征、三种服务模型、四种部署模式）压在最下层，架构主线（虚拟化、分布式存储、平台技术、安全机制）横在中间，应用场景与安全对策浮在最上层，最后用易错点和复习清单把整个体系串起来。这份讲义性质的答案集适合两类人：正在系统学云计算、想把零散章节串成一张网的，以及考前需要快速定位薄弱点、不愿意从头再读一遍教材的。

2. 概念底座：五大特征、三种服务模型与四种部署模式怎么区分

这一章是全书的起点，也是最容易被轻视的部分。很多人在复习时把概念题当成“背了就能拿分”的送分题，结果一到综合题就露馅，因为服务模型的选择、部署模式的取舍，本质上都是在用这几条基础定义做推理。真正扎实的做法是把这几组概念当成一套判断工具，而不是三段需要默写的文字。

2.1 五大特征：每一条都在回答“凭什么算云”

云计算的五个基本特征分别是按需自服务、广泛网络接入、资源池化、快速弹性、可计量服务。单看名字都很眼熟，但考试和面试真正考的是“给你一个场景，判断它算不算云计算”，这时候就需要把每条特征翻译成一个可观察的现象。按需自服务对应的是用户能自助开通资源、不需要人工审批和工单；广泛网络接入对应的是标准协议和任意终端，而不是只能在机房内网访问；资源池化对应的是多租户共享同一批物理资源、用户不关心资源的具体位置；快速弹性对应的是容量能随负载快速扩缩、对用户近似无限；可计量服务对应的是资源使用量能被精确度量，这是按使用量计费的前提。

这一节的难点不在记忆，而在于区分“资源池化”和“虚拟化”。虚拟化是实现资源池化的技术手段之一，但资源池化强调的是一种服务形态：多个用户共享同一资源池且彼此隔离。把这两者混为一谈，后面架构设计部分的题基本都会连带出错。自测方法很简单，拿身边任何一个系统，逐条对照上表打勾，五条全中才叫云，缺一条就要说出缺在哪、属于哪种过渡形态。

2.2 三种服务模型：IaaS、PaaS、SaaS 的责任边界怎么划

服务模型这一组概念几乎每套题都会出现，但失分点往往不在定义，而在责任边界的划分。IaaS 提供的是计算、存储、网络等基础资源，用户拿到的是虚拟机和虚拟网络，操作系统及以上全部自己管；PaaS 提供的是开发运行环境和中间件，用户只管应用和数据，操作系统与运行时由服务商负责；SaaS 提供的是可直接使用的完整应用，用户只负责配置和使用，其余全归服务商。

记这张表有个口诀：SaaS 拿来就用，PaaS 拿来就开发，IaaS 拿来就装系统。真正容易出错的是中间那一格，数据库归谁管。在 IaaS 里数据库要用户自己安装、自己调优、自己备份；在 PaaS 里数据库是对外提供的一项服务，用户只管库表结构和数据。同样是“用数据库”，两种模型下的运维责任完全不同，题目问“迁移到 PaaS 后运维工作减少了什么”，答案必须落到中间件和运行时的托管上，而不是笼统地说“减少了运维”。

这一节的第二个难点是判断某个具体产品属于哪一层。判断标准只有一个：看用户拿到的最高层抽象是什么。拿到的是裸资源和操作系统安装权，就是 IaaS；拿到的是运行环境和部署入口，就是 PaaS；拿到的是登录即用的界面，就是 SaaS。不要按产品名气判断，也不要把“带管理控制台”当作 PaaS 的标志。

2.3 四种部署模式：公有云、私有云、混合云、社区云的判分关键词

部署模式的四种形态分别是公有云、私有云、混合云和社区云。公有云面向公众开放、多租户共享，基础设施由服务商拥有和运营；私有云只服务单一组织，可以由组织自建自营，也可以托管在第三方机房，关键看资源是否专供这一个组织；混合云是两种及以上部署模式的组合，并且这些云之间存在数据和应用的可移植性；社区云由若干具有共同关切的组织共同使用和管理，这个“共同关切”通常指合规要求、安全等级或业务目标。

这里有一组极易混淆的概念：混合云和多云。多云只是用了两家以上公有云，彼此独立、没有统一编排、数据也不一定能在其间流动，这不构成混合云。混合云的核心判据是“可移植性”，即应用和数据能在私有部分与公有部分之间按需迁移，通常还伴随统一的身份、网络和编排。答题时只要把“可移植性”和“统一管理”这两个词写进去，基本就不会被判成泛泛而谈。

这一节的难点是私有云和传统自建机房的分界。判断依据仍然回到五大特征：有没有自助门户、有没有资源池化、有没有计量。一个机房如果只是把服务器分给不同项目组、扩容还要走采购流程，那就是传统模式，不是私有云。相反，一个托管在外部机房但资源专供、具备自助开通和计量的环境，完全可以是私有云。位置不决定性质，服务形态才决定性质。

3. 架构主线：虚拟化、分布式存储与平台技术的复习重点

概念层决定了“是什么”，架构层决定“怎么搭”。这一章是整本答案集里计算量和细节最多的地方，也是最容易在简答题里写出一堆名词却拿不到分的地方。复习顺序建议按资源类型走：先算力怎么切分，再数据怎么摆放，最后平台怎么把这些资源调度起来并管住边界。

3.1 虚拟化技术：拆分粒度决定了整条链路的性能

虚拟化的定义是把物理资源抽象成多个相互隔离的逻辑资源。按资源类型分，有 CPU 虚拟化、内存虚拟化、存储虚拟化和网络虚拟化；按实现方式分，有全虚拟化、半虚拟化和硬件辅助虚拟化；按 Hypervisor 所处的位置分，有裸金属型（直接跑在硬件上）和宿主型（跑在操作系统之上）。这三组分类经常被混着问，答题时先说清是按哪个维度分类，再列举，层次立刻就清楚了。

真正需要算的是资源超分。超分比指的是分配给虚拟机的逻辑资源与实际物理资源的比值。CPU 可以放心超分，因为绝大多数业务不会持续跑满；内存则要谨慎，超分过多会触发交换，性能会以断崖式下跌的方式表现出来。估算一台宿主机能承载多少台虚拟机，要把 CPU 和内存两个维度分别算一遍，取较小值。

# 按 CPU 与内存两个维度估算单台宿主机可承载的虚拟机数量 # 超分比 = 分配给虚拟机的逻辑资源 / 实际物理资源 def vm_capacity(cores, cpu_ratio, vcpu_per_vm, mem_gb, mem_ratio, mem_per_vm): by_cpu = int(cores * cpu_ratio // vcpu_per_vm) # CPU 维度上限 by_mem = int(mem_gb * mem_ratio // mem_per_vm) # 内存维度上限 return min(by_cpu, by_mem), by_cpu, by_mem # 32 物理核、CPU 超分 4 倍、每台虚拟机 4 vCPU # 384 GB 内存、内存超分 1.0、每台虚拟机 16 GB n, by_cpu, by_mem = vm_capacity(32, 4, 4, 384, 1.0, 16) print(n, by_cpu, by_mem) # 24 32 24

这段代码的逻辑是分别计算两个维度的容量上限再取小值。参数里cpu_ratio是 CPU 超分比，取 4 意味着每 1 个物理核对外承诺 4 个 vCPU；mem_ratio是内存超分比，通常贴近 1.0，最多不超过 1.2；vcpu_per_vm和mem_per_vm是单台虚拟机的规格。结果说明这台机器在 CPU 维度能开 32 台，但内存维度只能开 24 台，所以实际容量是 24 台。这类题最常见的错误是只算 CPU，或者把两个维度的结果相加，这两种答法都会暴露对资源约束的理解不到位。

这一节的重点还有虚拟机和容器的差别。虚拟机隔离的是整个操作系统，每台都有独立内核，启动在分钟级；容器共享宿主内核，靠命名空间做隔离、靠控制组做资源限制，启动在秒级甚至更快。答题时不要只说“容器更轻量”，要落到隔离级别和启动时间这两个可验证的差异上，再补一句“隔离强度与启动速度是一对取舍”。

3.2 分布式存储：副本、纠删码与可靠性计算

单机存储在容量、吞吐和可靠性上都有上限，分布式存储的思路是把数据分散到多台设备上，通过冗余来换取可靠性，通过并行来换取吞吐。这里面有三个必考的知识点：数据分布方式、冗余方式和一致性取舍。

数据分布常用的是一致性哈希，它相比简单的哈希取模，最大的优势是扩容或缩容时只需要迁移少量数据，而不是几乎全量重排。冗余方式有两大类：多副本和纠删码。三副本的存储开销是 3 倍，可用容量是原始容量的三分之一；纠删码把数据切成 k 个数据块、再生成 m 个校验块，存储开销是 (k+m)/k，能容忍任意 m 个块同时丢失。

# 对比多副本与纠删码：存储开销与同时失效概率（简化模型） afr = 0.02 # 单块磁盘的年故障率 def replica_loss(afr, n): return afr ** n # n 份副本同时失效的概率 def ec_overhead(k, m): return (k + m) / k # 实际占用容量 / 原始数据容量 print(replica_loss(afr, 3)) # 8e-06，三副本同时失效 print(ec_overhead(8, 2)) # 1.25，8 个数据块 + 2 个校验块 print(ec_overhead(4, 2)) # 1.5

这段计算只是一个示意，afr表示单块磁盘的年故障率，replica_loss假设各副本独立失效，因此三副本同时失效的概率是 0.02 的三次方。实际可靠性还要叠加重建窗口、同批次硬盘故障、机架与机房的相关性，所以真实数字会比这个简化模型差不少。ec_overhead算的是存储效率，8+2 的开销是 1.25 倍，明显优于三副本的 3 倍。那为什么不全用纠删码？因为纠删码重建时要读取大量数据块并做计算，读取放大和网络开销都更高，延迟也更敏感。多副本胜在恢复快、实现简单；纠删码胜在容量效率。答题时把这对取舍写清楚，比单纯背出两个名词有价值得多。

一致性方面要能说出 CAP 的基本结论：分布式系统必须容忍分区，所以实际是在一致性和可用性之间取舍。强一致适合交易类业务，最终一致适合可以容忍短暂不一致的场景，BASE 就是后者的工程化表述。这一节的难点不在概念，而在于把冗余方式和业务场景对应起来，比如冷数据归档用纠删码、热数据用多副本，这是能体现理解深度的地方。

3.3 平台技术与安全机制：资源的调度和边界的划定

平台技术解决的是资源怎么被高效、安全地用起来。核心能力有四项：资源调度、多租户隔离、计量计费、自动化编排。资源调度关注三类约束，资源需求是否满足、亲和与反亲和关系是否成立、租户配额是否超限；多租户隔离要同时覆盖计算、网络、存储和数据四个层面，只做其中一层等于没做；计量计费依赖对资源使用量的持续采集，这也是五大特征里“可计量服务”在架构上的落点；自动化编排把部署、扩缩、故障转移这些动作从人工操作变成声明式的流程。

安全机制在架构里不是一个独立模块，而是分布在多个层次上的。边界层负责网络隔离和访问控制，主机层负责补丁、加固和入侵检测，数据层负责加密和脱敏，身份层负责认证与授权，审计层负责留痕和追溯。这五层里最容易被忽略的是审计层，很多答案写到加密和防火墙就停笔了，实际上审计日志是事后定位问题的唯一依据，也是合规检查的硬性要求。

这一节的重点是把平台能力和前面的概念对应回去。调度对应资源池化，计量对应可计量服务，编排对应快速弹性，隔离对应多租户。能把这四条对应关系说清楚，说明概念层和架构层已经打通了，而不是两段互不相干的背诵材料。

4. 场景与安全：三条应用线加四类安全对策的配对记法

到了应用层，题目形态会从“是什么”变成“为什么”和“怎么办”。第三章讲的是系统的内部构造，这一章讲的是这套构造在真实场景里的价值体现，以及它在面对风险时的应对方式。这两部分经常被合并成一道大题，前半段问场景价值，后半段问安全对策，答的时候如果只罗列优点，分数会很有限。

4.1 三类应用场景：价值点必须落到具体机制上

云计算的应用场景大致分三类。企业应用包括企业资源规划、客户关系管理、供应链管理等，核心价值是提高资源利用率、降低成本、提高灵活性和可靠性；私人应用包括个人存储、个人计算、个人安全等，核心价值是更大的存储空间、更快的计算速度、更好的安全性；公共服务包括电子政务、电子商务、公共健康服务等，核心价值是弹性应对峰值、服务广泛可达、数据集中治理。

这张表的价值在于把“优点”和“机制”对应起来。答“云计算降低了企业成本”，这句话本身没有信息量；如果说“资源池化让多个业务共享同一批物理资源，闲置容量可以被其他业务复用，因此单位算力的成本下降”，这才叫答到了点上。同理，公共服务的峰值承载不是靠“云很强大”，而是靠弹性伸缩在短时间内扩容、事件结束后再缩容，避免为了一年的几次峰值长期保有冗余硬件。

这一节的难点是不要把所有价值点往所有场景上套。个人存储的核心诉求是容量和可达性，不是成本分摊；企业应用才会关心资源利用率和总体拥有成本。分不清场景和价值点的对应关系，答案就会显得空。

4.2 安全挑战与对策：一对一配对才不丢分

云计算面临的安全挑战主要有四类：数据泄露、未经授权的访问、恶意攻击和自然灾害。对应的策略分别是以身份与访问控制为核心、以数据加密为手段、以网络安全为屏障、以灾难恢复为兜底。这四组关系一定要成对记忆，因为题目常常给一个场景让你选对策，配错了等于没答。

这里有个容易被忽略的前提：安全责任是分担的。IaaS 下用户要管操作系统及以上，PaaS 下用户只管应用和数据，SaaS 下用户主要管账号和配置。同一道“谁负责打补丁”的题，换个服务模型答案就变了。把共享责任模型写进答案，往往是拉开分差的地方。

4.3 灾备与可用性：把口号换成能算的数字

灾备部分最容易写得空泛，“做好备份”“异地容灾”这类表述拿不到分。要拿分就得落到两个指标上：RTO 是恢复时间目标，指业务中断后多久必须恢复；RPO 是恢复点目标，指最多能容忍丢失多长时间的数据。这两个词方向相反，考场上写反的情况非常常见，记忆方法是 RTO 的 T 对应 Time，讲的是时间长短；RPO 的 P 对应 Point，讲的是恢复到哪个时间点。

可用性等级也要会换算。所谓“几个 9”，指的是全年可用时间占比中 9 的个数，换算成停机时间才能和灾备方案对上。

# 把“几个 9”换算成全年停机分钟数，用来反推灾备方案是否够用 def downtime_minutes(nines, days=365): return days * 24 * 60 * (10 ** -nines) for n in (3, 4, 5): print(n, round(downtime_minutes(n), 1)) # 3 → 525.6 分钟，约 8.76 小时 # 4 → 52.6 分钟 # 5 → 5.3 分钟

参数nines就是 9 的个数，days默认按 365 天算。这三个数字要能脱口而出，因为灾备方案的选择直接由它们决定：如果 RTO 要求 30 分钟以内，冷备方案（平时不启动、故障后现搭环境）基本不可能达标，只能选热备或双活；如果 RPO 要求接近 0，那就必须做同步复制或持续日志同步，而不是每天一次全量备份。另外配套记一下 3-2-1 备份原则：至少 3 份数据、存放在 2 种不同介质上、其中 1 份放在异地。这条原则在简答题里出现频率很高，而且能和“不可篡改备份”一起用来回答勒索攻击的防护。

5. 易错清单：五个最容易翻车的知识点与补法

复习到这一步，知识点基本都过了一遍，真正拉开差距的是那些“以为自己会了”的地方。下面这五条是从这套题里反复暴露出来的高频失分点，每一条都按“错在哪、为什么会错、怎么补”来说，对照自己的错题本看一遍，能省下不少重复劳动。

5.1 概念层：两个看起来成立的等价关系

易漏点一：把虚拟化等同于云计算。这是最经典的一条。虚拟化是一种资源抽象技术，解决的是“一台物理机怎么切成多台”的问题；云计算是一种服务模式，除了资源池化，还要求自助服务、网络接入、弹性伸缩和计量计费。有虚拟化没有自助门户和计量，那只是服务器整合，不是云。

为什么漏：教材里虚拟化章节紧跟在云计算概述后面，两个词的出现频率都很高，读的时候很容易形成“虚拟化是云计算的技术实现”这种过度简化的印象。补法是把五大特征当成五道判断题，任何声称“这是云计算”的系统都要逐条过一遍，尤其是“按需自服务”和“可计量服务”这两条，传统虚拟化环境通常都不满足。

易漏点二：把混合云理解成“用了两家云”。混合云的核心判据是可移植性和统一管理，即应用和数据能在私有部分与公有部分之间迁移，通常还有统一的身份和编排。两家互不相干的公有云同时在使用，那叫多云，不叫混合云。

为什么漏：日常语境里“混合”这个词太日常了，容易按字面理解。补法是记住一个反问句：这两朵云之间，应用能不能迁过去、数据能不能流过去、身份是不是同一套？三个都否，就不是混合云。

5.2 模型层：责任边界那根线画在哪里

易漏点三：服务模型的责任边界画错，尤其是 PaaS。常见错误是把 PaaS 说成“提供了操作系统”，或者把 IaaS 说成“连中间件都不用管”。正确的分界是：IaaS 下用户管操作系统及以上，PaaS 下用户管应用和数据，操作系统与运行时归服务商。

为什么漏：PaaS 这个词的“平台”太模糊，不同资料对平台包含的范围描述不完全一致，加上中间件和数据库在不同服务里归属不同，很容易记串。补法是抓一条主线：谁负责打操作系统的补丁，谁就负责那一层。IaaS 用户要自己打补丁，PaaS 用户不用，这条线一划，上下就都清楚了。再补一句共享责任模型，说明安全责任随服务模型上移而转移，答案立刻完整。

5.3 指标与表述层：数字和关键词上的明显错误

易漏点四：RTO 和 RPO 写反，可用性的“9”算错量级。RTO 是恢复时间目标，RPO 是恢复点目标，一个讲多久能恢复、一个讲能丢多少数据。可用性换算则常被错算成每月停机时间，三个 9 对应的是全年约 8.76 小时，不是每月 8.76 小时。

为什么漏：这两个缩写长得很像，中文翻译又都带“恢复”二字，背的时候只记了中文没记英文全称。补法是记全称，Recovery Time Objective 和 Recovery Point Objective，再用一句场景话固化：数据库崩了，RPO 决定你回到几点几分的数据，RTO 决定你几点几分能重新对外服务。停机时间换算则建议手算一遍 365×24×60 再乘比例，算过一次就不会再错量级。

易漏点五：安全题只答“加密”两个字。加密要分场景：传输加密解决链路窃听，静态加密解决存储介质被拿走，密钥管理解决加密本身的安全。只写“对数据加密”，等于什么都没说。

为什么漏：加密是安全题里最容易想到的词，想到就写，写完就过，来不及想它落在哪个环节。补法是强迫自己按“传输、存储、使用、销毁”四个环节各写一句，再补一句密钥托管在哪里。四句话写下来，即使不够深入，覆盖面上也不会失分。这套方法在血泪经验里是性价比最高的：不需要多背知识，只需要把一个词展开成四个位置。

6. 复习清单：把答案集当检查表的六步自查流程

把整本书过完之后，最后一个动作不该是再读一遍，而是拿一张纸做一次自查。下面这套流程按“从粗到细”的顺序排，每一步都有明确的产出物，走完一遍大概四十分钟，比重读一章的效率高得多。

6.1 六步自查流程

第一步，默画知识地图。不看书，写出四层结构：概念底座、架构主线、应用场景、安全与运维，并在每层下面写出三个以上的关键词。写不出来的那一层，就是下一轮复习的起点。

第二步，遮住表格右列自测概念。把五大特征、三种服务模型、四种部署模式三张表的右列遮住，只看左列复述定义和判分关键词。这一步的达标标准是能用一句话说清每个概念的边界，而不是背出原文。

第三步，重画一遍责任边界。拿一张纸，横向写 IaaS、PaaS、SaaS，纵向写应用、运行时、操作系统、虚拟化、硬件，逐格填“用户”或“服务商”。填完对照本章的表格，错一格就说明这一层还没吃透。

第四步，手算三个数字。一台宿主机按超分比能开多少台虚拟机、三副本与 8+2 纠删码的存储开销、三个 9 对应的全年停机分钟数。这三个计算覆盖了架构和灾备两块的核心考点，手算一遍比看十遍公式管用。

第五步，场景题三连。随便挑一个场景，比如某单位的公共健康服务，按“它用了哪种服务模型、依赖哪几条特征、对应哪些安全对策”三连作答。三连答得顺，说明概念、架构、安全三层已经串起来了。

第六步，错题归因。把做错的题按四类归档：概念不清、边界画错、计算失误、表述空泛。这四类的补法完全不同，概念不清要回去重读定义，边界画错要重画责任矩阵，计算失误只需重算一遍，表述空泛则要积累答题句式。不分类的错题本基本等于没有。

6.2 一句提醒

这套流程里最容易被跳过的是第五步，因为它没有标准答案，写起来最费劲。但恰恰是这一步能把前面四步的知识粘起来。从那以后我每次复习这类体系性强的科目，都强制自己走一遍“默画地图、遮表自测、重画边界、手算数字、场景三连、错题归因”，哪怕时间不够，也要把第一步和第五步做完，因为这两步决定了知识是散点还是网络。

这份答案集的价值不在于给出标准答案，而在于它把概念、架构、场景、安全四条线都覆盖到了，正好可以当一张检查表用。需要完整版的话，按文末方式获取即可，对照着自己的错题本过一遍，比从头再刷一遍题要省力得多。希望帮到你。

本文还有配套的精品资源，点击获取