Cloud Computing 复习重点
这份资料按考试大题来整理，不按课件顺序机械摘抄。目标是让你能快速查阅、背诵、画图，并在考试中写出完整答案。
最重要Cloud 基础、VM、Container、Serverless、Storage
新课件重点MapReduce、Ray、Kubernetes、Knative
旧卷常考RAID、SAN/NAS、HDFS、Docker、FaaS、AWS 方案题
答题策略定义 + 原理 + 优缺点 + 场景例子 + 图
0. 复习策略：先保 4 个大题包
必背
高频
当前课件重点
考试通常是 5 道大题选 4 道，每题 25 分。所以策略不是全部细节平均背，而是先准备 4 个能稳定写满的大题包。
| 大题包 | 包含内容 | 目标 |
|---|---|---|
| A. Cloud Fundamentals | Cloud 定义、5 个 essential characteristics、IaaS/PaaS/SaaS、Public/Private/Hybrid | 基础题直接拿分 |
| B. Execution Models | VM、Container、Serverless 三者比较；Hypervisor；Docker workflow；FaaS | 对比题和定义题稳 |
| C. Scaling / Fault Tolerance / AWS | Scale up/out、auto-scaling、load balancing、replication、AWS 架构设计 | 场景设计题能写 6–8 点 |
| D. Data + Orchestration | Object/Block/File、MapReduce、Ray、Kubernetes、Knative | 覆盖当前课程新增重点 |
考场原则：如果题目要求 “describe / explain / compare / design”，不要只写定义。必须写：定义 → 工作原理 → 优点 → 缺点 → 例子 / 图。
1. Cloud Computing 基础
必背 旧卷 Q1 高频1.1 Cloud Computing 定义
一句话记忆：Cloud computing 是一种通过网络按需访问共享计算资源池的模型，资源可以快速 provision / release，用户只需很少管理工作。
标准答案可写：
Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources such as networks, servers, storage, applications, and services. These resources can be rapidly provisioned and released with minimal management effort or service provider interaction.
1.2 五个 Essential Characteristics
| 特征 | 中文理解 | 考试怎么写 |
|---|---|---|
| On-demand self-service | 用户自己按需开资源 | Users can provision computing resources automatically without human interaction with the provider. |
| Broad network access | 通过网络访问 | Resources are available over the network and accessed by standard mechanisms. |
| Resource pooling | 资源池共享 | Provider resources are pooled to serve multiple users using multi-tenancy. |
| Rapid elasticity | 快速扩缩容 | Resources can be scaled out or in quickly according to demand. |
| Measured service | 按量计费 | Resource usage can be monitored, controlled, reported, and billed. |
1.3 Service Models：IaaS / PaaS / SaaS
| Model | 用户管理 | 云商管理 | 例子 | 一句话 |
|---|---|---|---|---|
| IaaS | OS、runtime、application、data | 服务器、网络、存储、虚拟化层 | EC2, Azure VM | 租基础设施，自己装系统和软件 |
| PaaS | Application、data | OS、runtime、middleware、infra | Heroku, Google App Engine | 只管代码，平台管运行环境 |
| SaaS | 使用应用 | 几乎全部 | Gmail, Office 365 | 直接用软件服务 |
1.4 Deployment Models
| Model | 定义 | 优点 | 缺点 |
|---|---|---|---|
| Public Cloud | 第三方云商提供，多个客户共享 | 便宜、弹性强、无需自建 | 控制弱、安全/合规顾虑 |
| Private Cloud | 一个组织独占的云环境 | 控制强、安全合规好 | 成本高、维护复杂、弹性有限 |
| Hybrid Cloud | Public + Private 组合 | 敏感数据留本地，峰值负载上公有云 | 集成、网络、安全策略复杂 |
2. 分布式系统、Scaling、Fault Tolerance
必背 设计题底层逻辑2.1 Distributed System 定义
一句话记忆：很多计算机通过网络和 middleware 协作，但用户看起来像一个整体系统。
完整答法：
A distributed system is a collection of computers connected through a network and coordinated by middleware. The computers share resources and coordinate activities, while users perceive the system as a single integrated computing facility.
2.2 为什么 Cloud 依赖分布式系统？
- 要同时服务大量 users 和 requests。
- 要处理 large volumes of data。
- 应用通常运行在 multiple machines 上。
- 需求变化时要 scale resources。
- 部分机器失败时系统仍要 continue operating。
2.3 Desirable Properties
| Property | 意思 | 例子 |
|---|---|---|
| Access transparency | 本地/远程资源访问方式一样 | 访问远程文件像访问本地文件 |
| Location transparency | 用户不用知道资源在哪 | 用户不知道数据在哪个 region |
| Replication transparency | 副本存在但用户无感 | 数据库有多个 replica |
| Failure transparency | 隐藏部分故障 | 某台 server 挂了，服务继续可用 |
| Scaling transparency | 扩容不影响用户/应用 | 增加节点后接口不变 |
2.4 Scale Up vs Scale Out
| 类型 | 定义 | 优点 | 缺点 |
|---|---|---|---|
| Scale up / Vertical | 给单台机器加 CPU/RAM/Storage | 简单，架构变化少 | 单机上限、贵、可能 downtime |
| Scale out / Horizontal | 增加更多机器，分担 workload | 弹性强、容错好、适合云 | 需要分布式协调、load balancing、数据一致性处理 |
2.5 Under-provisioning vs Over-provisioning
| 问题 | 解释 | 后果 | 云如何解决 |
|---|---|---|---|
| Under-provisioning | 资源买少了 | 高延迟、请求失败、用户流失 | Auto-scaling 增加实例 |
| Over-provisioning | 资源买多了 | 非高峰期浪费成本 | 按需释放资源，pay-as-you-go |
2.6 Auto-scaling + Load Balancing
Auto-scaling
根据 CPU usage、request rate、queue length 等指标自动增加或减少实例。
作用：应对峰值负载，减少闲置成本。
Load Balancing
把请求分发到多个 healthy instances，避免单点过载。
作用：提高 throughput、availability、fault tolerance。
Users
↓
Load Balancer
↓ ↓ ↓
VM1 VM2 VM3
↑
Auto-scaling group 根据负载增加/减少 VM
3. Virtual Machines 与 Hypervisors
必背 旧卷 Q2 高频3.1 Virtualization 定义
Virtualization abstracts physical computing resources and creates virtual versions of them. It allows multiple logically isolated virtual machines to run on the same physical hardware.
3.2 VM 是什么？
VM 是一个 software-defined computing environment。它像独立电脑一样运行，有自己的：
- Guest operating system
- Applications
- Virtual CPU
- Virtual memory
- Virtual disk
- Virtual network interface
Applications
Guest OS
Virtual CPU / Virtual Memory / Virtual Disk / Virtual NIC
Hypervisor / Virtualization Layer
Physical Hardware
3.3 Hypervisor
Hypervisor 是创建、运行、管理 VMs 的软件层。它负责分配 CPU、memory、storage、networking，并隔离不同 VM。
| 类型 | 运行位置 | 优点 | 典型用途 | 例子 |
|---|---|---|---|---|
| Type 1 / Bare-metal | 直接运行在物理硬件上 | 性能好、overhead 低、隔离强 | 数据中心、公有云 | VMware ESXi, Xen, Hyper-V |
| Type 2 / Hosted | 运行在 host OS 上 | 安装简单，适合个人电脑 | 教学、测试、开发 | VirtualBox, VMware Workstation |
3.4 为什么 Cloud 平台常用 Type 1？
- 直接控制硬件，overhead 更低。
- 适合 large-scale VM hosting。
- 支持 strong isolation。
- 适合 IaaS，能快速 provision/release VM。
考试高频句：VMs virtualize hardware and run full guest operating systems. This gives strong isolation and OS flexibility, but they are heavier and slower to start than containers.
4. Containers 与 Docker
必背 Docker workflow 常考4.1 Container 定义
A container packages an application with the dependencies and configuration it needs to run. It shares the host operating system kernel and provides lightweight, process-isolated execution.
4.2 VM vs Container
| 比较点 | VM | Container |
|---|---|---|
| 虚拟化层级 | Hardware-level virtualization | OS-level virtualization |
| OS | 每个 VM 有 guest OS | 共享 host kernel |
| Isolation | 更强 | 相对弱，因为共享 kernel |
| Startup | 较慢，需要 boot guest OS | 快，启动 isolated process |
| Overhead | 高 | 低 |
| 适合 | 多 OS、强隔离、IaaS | 微服务、快速部署、弹性扩展 |
4.3 Namespaces 与 cgroups
| 机制 | 作用 | 记忆 |
|---|---|---|
| Namespaces | 隔离进程能“看到”的系统视图，如 PID、filesystem、network、hostname | 隔离视野：see separately |
| cgroups | 限制和管理资源使用，如 CPU、memory、I/O | 控制资源：use fairly |
一句话：Namespaces provide isolation; cgroups provide resource control.
4.4 Docker 三个核心概念
| 概念 | 定义 | 类比 |
|---|---|---|
| Image | 包含 app、runtime、libraries、dependencies 的 reusable template | 菜谱 / 模板 |
| Registry | 存储和分发 images 的服务 | 镜像仓库 |
| Container | 由 image 创建出来的 running instance | 真正跑起来的应用 |
4.5 Docker Workflow
Developer writes Dockerfile
↓
docker build
↓
Docker Image
↓
docker push / pull
↓
Registry
↓
docker run
↓
Running Container
能写的 5 个 workflow：
- Write a Dockerfile.
- Build an image.
- Store or share the image in a registry.
- Pull the image on another machine.
- Run the image as a container.
- Stop, remove, or update containers.
5. Serverless / FaaS / BaaS
必背 旧卷问过 FaaS drawbacks5.1 Serverless 定义
Serverless computing is a cloud execution model in which developers deploy code or use managed services, while the cloud provider handles much of the provisioning, scaling, and runtime management.
注意：Serverless 不等于没有服务器。代码仍然跑在真实服务器上，只是服务器管理责任从 developer 转移给 cloud provider。
5.2 VM → Container → Serverless
| Aspect | VM | Container | Serverless |
|---|---|---|---|
| Deploy | VM image | Container image | Function / code |
| Manage | VM、Guest OS、software stack | Container service/runtime | Mainly application logic |
| Execution | Long-running instance | Long-running service/container | Event-driven, on demand |
| Scaling | Provision more VMs | Orchestrate containers | Platform scales automatically |
5.3 FaaS 与 BaaS
FaaS: Function as a Service
开发者部署单个函数，函数由事件触发，平台按需运行并自动扩展。
例子：HTTP request、file upload、queue message、timer。
BaaS: Backend as a Service
云商提供现成后端能力，开发者通过 API 使用。
例子：storage、database、authentication、messaging、notification。
5.4 Serverless Application 五个元素
Event Source
↓
Trigger
↓
Function
↓
Backend Services
↓
Output / Destination
5.5 Invocation
| 类型 | 解释 | 例子 |
|---|---|---|
| Synchronous invocation | caller 发请求并等待结果 | HTTP/API request-response |
| Asynchronous invocation | caller 发事件后不等待，平台排队/稍后处理 | File upload、notification、background job |
5.6 FaaS 缺点
| 缺点 | 解释 |
|---|---|
| Cold start | 第一次调用或扩容时要创建 execution environment，导致延迟。 |
| Vendor lock-in | 依赖特定云商的 API、trigger、deployment model。 |
| Limited execution time | 不适合长期运行任务。 |
| Statelessness | 函数通常无状态，状态要放到外部数据库/存储。 |
| Debugging harder | 事件驱动、分布式调用链导致调试和观测更难。 |
| Performance unpredictability | 平台调度和 cold start 会导致延迟波动。 |
6. Storage Models：Object / Block / File
必背 场景选型题高频6.1 为什么 Storage 是 Cloud 的核心问题？
- 数据要在 VM / container / function 生命周期结束后继续存在。
- 数据要被 distributed services 和 users 共享。
- 数据量会随应用增长而 scale。
- 故障发生时数据仍要 available and durable。
- 要支持 analytics、monitoring、machine learning workflows。
6.2 三种核心 Storage Model
| Model | 定义 | 适合 | 不适合 |
|---|---|---|---|
| Object Storage | 数据作为 objects 存储，通过 API 和 key 访问 | 图片、视频、日志、备份、归档、analytics dataset、ML checkpoints | 频繁 in-place 修改、传统文件路径、低层 block 控制 |
| Block Storage | 提供 raw storage blocks / volume，由 OS 或应用管理布局 | VM boot disk、database volume、container persistent volume | 共享文件夹、object API 访问、大规模媒体归档 |
| File Storage | 以 files 和 directories 暴露，支持 filesystem semantics | 共享目录、团队文档、传统软件需要 path/folder | 超大规模 object-style 数据、底层 block 控制 |
6.3 场景判断口诀
Object
“大文件 + API + key + 不常改”
视频、图片、log、archive。
Block
“像硬盘一样挂给 OS”
VM boot disk、数据库卷。
File
“像共享文件夹一样用”
reports、documents、shared directory。
6.4 Database Services
不是所有数据都适合直接放 object/block/file。结构化业务数据通常用 database services。
| 数据 | 更适合 | 原因 |
|---|---|---|
| User profiles / bookings / payments | Relational database | 需要 structured query、consistency、transaction |
| Clickstream / logs | Object storage + analytics service | 数据量大，适合批处理和分析 |
| Photos / videos | Object storage | 非结构化、大对象、可扩展 |
| Shared documents | File storage | 需要文件夹和路径语义 |
7. MapReduce
当前课件重点 必背流程7.1 为什么需要 MapReduce？
单机处理大量网页 / 日志 / 文档时，会遇到 storage、memory、I/O、processing time 瓶颈。MapReduce 用分布式方式解决大规模批处理问题。
7.2 MapReduce 定义
MapReduce is a programming model for processing large quantities of data. It expresses the computation using two main functions: map and reduce. The map function emits intermediate key-value pairs, the shuffle stage groups values by key, and the reduce function aggregates the values for each key.
7.3 Core Picture
Input
↓
Map
↓
Shuffle / Sort
↓
Reduce
↓
Output
7.4 Programming Model
map(k1, v1) → list(k2, v2)
reduce(k2, list(v2)) → output
7.5 Word Count 例子
| 阶段 | 输入 / 输出 | 解释 |
|---|---|---|
| Input | "car river car bear" | 一行文本 |
| Map | (car,1), (river,1), (car,1), (bear,1) | 每个词 emit 一个 key-value pair |
| Shuffle | car → [1,1], river → [1], bear → [1] | 相同 key 聚在一起 |
| Reduce | car → 2, river → 1, bear → 1 | 对每个 key 的 values 求和 |
7.6 MapReduce 适合 / 不适合
| 适合 | 不适合 |
|---|---|
|
|
8. Ray
当前课件重点8.1 Ray 是什么？
Ray is a distributed execution framework for Python applications, especially useful for flexible AI and data-processing workloads. It allows Python functions to run remotely, stateful objects to live remotely, work to run across CPU and GPU nodes, and dependencies between tasks to be tracked automatically.
8.2 为什么 MapReduce 不够？
MapReduce 适合固定的 batch pipeline：map → shuffle → reduce。但现代 AI workload 常常需要：
- Iteration：反复训练 / 调参。
- Dynamic decisions：根据早期结果停止弱模型，启动新任务。
- Stateful workers：模型或环境需要保持状态。
- Mixed CPU/GPU resources：不同任务需要不同资源。
- Evolving dependencies：任务依赖在运行中变化。
8.3 Ray Core Concepts
| Concept | Meaning | Used for |
|---|---|---|
| Task | Remote stateless function | Parallel independent work |
| Actor | Remote stateful object | Stateful services, simulations, model serving |
| Object | Data stored in Ray distributed object store | Sharing intermediate results |
| Object reference | Handle pointing to remote result | Passing dependencies between tasks |
8.4 MapReduce vs Ray
| MapReduce | Ray |
|---|---|
| Fixed map → shuffle → reduce | Dynamic task graph |
| Batch-oriented | Flexible execution |
| Mostly stateless stages | Stateless tasks + stateful actors |
| Natural key-based aggregation | General Python functions/classes |
| Good for large batch analytics | Good for dynamic AI/Python workloads |
9. Cloud Resource Orchestration / Kubernetes / Knative
当前课件重点 理解题 / 对比题9.1 Orchestration 是什么？
Cloud resource orchestration is the automated control of shared cloud resources across many applications. It continuously observes the system state, decides whether action is needed, and acts by scaling, placing, restarting, or reallocating workloads.
Observe
↓
Decide
↓
Act
↓
Adjust
↺ repeat
9.2 Policy vs Mechanism
| 概念 | 意思 | 例子 |
|---|---|---|
| Policy | 决策目标：what should happen | Protect latency-sensitive service |
| Mechanism | 执行方法：how to enforce it | Priority scheduling, admission control, autoscaling |
9.3 Cloud Platform 要持续决定什么？
- Which workloads should be accepted?
- Where should each workload run?
- How much CPU, memory, storage, bandwidth to allocate?
- When should applications scale up or down?
- How to handle unhealthy tasks or failed machines?
- How to reduce cost and energy waste without breaking QoS?
9.4 Borg / Kubernetes / Knative
| 系统 | 核心抽象 | 一句话 |
|---|---|---|
| Borg | Jobs, tasks, priority, quota, recovery | Google 大规模 cluster-management reference |
| Kubernetes | Pods, ReplicaSets, Deployments, controllers | 容器化 workload 的 desired-state orchestration |
| Knative | Request/event-driven services, scale-to-zero | 在 Kubernetes 上提供 serverless 行为 |
9.5 Kubernetes 核心概念
| 概念 | 解释 |
|---|---|
| Pod | Kubernetes 管理的最小 workload 单位，可包含一个主容器和 helper containers。 |
| Node | 运行 Pods 的 worker machine。 |
| Control Plane | 协调 cluster，维护 desired state。 |
| Scheduler | 选择 Pod 应该运行在哪个 Node 上。 |
| Controller | 不断比较 desired state 和 actual state，并修正差异。 |
| ReplicaSet | 保证指定数量的 Pod replicas 运行。 |
| Deployment | 管理应用部署、滚动更新、回滚。 |
| Service | 给一组 Pods 提供稳定访问入口。 |
9.6 Desired State 与 Reconciliation
一句话：Kubernetes 不是只创建资源一次，而是不断把 actual state 拉回 declared desired state。
User declares desired state
↓
API Server stores state
↓
Scheduler selects worker node
↓
Worker starts Pod
↓
Status reported back
↓
Controller reconciles continuously
9.7 Same Pod or Separate Pods?
| Same Pod | Separate Pods |
|---|---|
|
|
9.8 Knative 与 Scale-to-zero
Knative 在 Kubernetes 上添加 request-driven / event-driven serverless behavior。核心是服务可以在没有请求时缩到 0，节省资源。
| 优点 | 缺点 |
|---|---|
| 节省 idle resources，提高资源利用率，适合间歇性 workload | 重新激活服务会有 latency，类似 cold start |
10. 旧卷补充考点：RAID / SAN-NAS / HDFS / AWS
旧卷高频10.1 RAID
RAID = Redundant Array of Independent Disks。用多个磁盘组合来提高性能、容量或容错能力。
| RAID | 机制 | 优点 | 缺点 |
|---|---|---|---|
| RAID 0 | Striping | 性能高、容量利用率高 | 没有容错，一块盘坏数据就坏 |
| RAID 1 | Mirroring | 容错好，读性能可能提升 | 容量利用率低，成本高 |
| RAID 5 | Striping + parity | 性能、容量、容错较平衡，可容忍一块盘坏 | 写入有 parity overhead，重建慢 |
10.2 SAN vs NAS
| 比较点 | SAN | NAS |
|---|---|---|
| 访问层级 | Block-level | File-level |
| 网络 | 常用 Fibre Channel / iSCSI | 常用 Ethernet / TCP/IP |
| 用户看到 | 像本地磁盘 volume | 像共享文件夹 |
| 适合 | 数据库、高性能存储、VM volumes | 文件共享、文档、home directories |
| 复杂度 | 较高 | 较低 |
| 成本 | 较高 | 通常较低 |
10.3 HDFS
HDFS = Hadoop Distributed File System。它把大文件切成 blocks，分布到多个 DataNodes，并通过 replication 提供容错。
Client
↓
NameNode: metadata, block locations
↓
DataNodes: store actual data blocks with replicas
- NameNode 管 metadata，不存真实文件内容。
- DataNode 存 blocks。
- Replication 提高 fault tolerance。
- 适合 large sequential read/write，不适合大量小文件和低延迟随机访问。
10.4 AWS 场景设计题模板
遇到“把系统迁移到 AWS / cloud solution design”的题，可以按下面 8 点写：
| 层 | AWS 产品 | 为什么 |
|---|---|---|
| DNS | Route 53 | 域名解析，流量导向服务 |
| CDN | CloudFront | 加速图片/视频/静态内容，降低延迟 |
| Load balancing | Elastic Load Balancer | 分发流量，健康检查，提高可用性 |
| Compute | EC2 Auto Scaling / ECS / EKS | 根据 6–8pm 高峰扩容，低谷缩容 |
| Structured data | RDS / Aurora | 订单、用户、菜单、支付等结构化数据 |
| Media | S3 | 菜单图片、视频、日志归档 |
| Monitoring | CloudWatch | 监控 CPU、requests、latency，触发扩缩容 |
| Security | IAM / VPC / Security Groups | 权限隔离、网络安全 |
11. 考试答题模板
11.1 概念题模板
Definition: 先用 1–2 句定义。
How it works: 写 2–4 个步骤或组件。
Advantages: 写 2–3 个优点。
Limitations: 写 1–2 个缺点。
Example: 给 cloud 场景例子。
How it works: 写 2–4 个步骤或组件。
Advantages: 写 2–3 个优点。
Limitations: 写 1–2 个缺点。
Example: 给 cloud 场景例子。
11.2 对比题模板
| Aspect | A | B |
|---|---|---|
| Definition | ... | ... |
| Isolation | ... | ... |
| Performance / overhead | ... | ... |
| Scalability | ... | ... |
| Use case | ... | ... |
| Limitations | ... | ... |
11.3 场景设计题模板
- 先识别 workload：用户量、峰值、数据类型、延迟、安全、合规。
- Compute：VM / container / serverless 选哪个？为什么？
- Scaling：如何 auto-scale？用什么指标？
- Load balancing：如何分发流量和健康检查？
- Storage：object / block / file / database 怎么选？
- Fault tolerance：多副本、多 AZ、backup、replication。
- Monitoring：metrics、logs、alerts。
- Security：IAM、network isolation、encryption。
11.4 万能图：Cloud Web App
Users
↓
DNS / CDN
↓
Load Balancer
↓
Auto Scaling Compute Layer
↓ ↓
Database Object Storage
↓
Monitoring + Security + Backup
12. 考前 Checklist
下面这些能闭卷写出来，就基本能上考场。
最后一天怎么复习？
- 先默写 Cloud 基础、VM、Container、Serverless 四大定义。
- 再默写 VM vs Container vs Serverless 表格。
- 画 Docker workflow、MapReduce workflow、Kubernetes control path 三张图。
- 用 AWS 模板练一遍场景设计题。
- 旧卷考点只补 RAID / SAN-NAS / HDFS / FaaS drawbacks。
最终提醒：这门课的答案不要写成中文碎片。考试时用英文短句 + 表格结构 + 图，会比长段废话更稳。