简介这份云计算课件面向高校计算机相关专业学生、云计算入门学习者及需要备课的教师系统梳理云计算从概念到落地的完整知识框架帮助读者建立对云服务体系与底层技术的整体认知。资源包共1个文件为1份ppt演示文稿压缩包大小约1.61MB内容以幻灯片形式组织便于课堂讲解与自学浏览。课件围绕云计算的定义、特点、分类与应用场景展开涵盖IaaS、PaaS、SaaS三种服务模式及公有云、私有云、混合云等部署形态并延伸至并行计算、分布式计算、网格计算等技术脉络结合SETIhome、Foldinghome等经典分布式项目案例以及云计算架构分层与数据安全、访问控制等议题帮助读者理解计算资源从集中到分散再到集中的演进逻辑。目前已有445人学习浏览适合作为课程配套资料或自学入门参考。1. 云计算课件从“讲不清”到“能跑通”的那层窗户纸很多工程师第一次接手云计算课件开发都会掉进同一个坑把课件做成产品白皮书的翻版满屏 IaaS、PaaS、SaaS 分层图学生看完还是不知道虚拟机是怎么被创建出来的。我见过太多团队花三个月打磨动画和配图最后交付的课件在真实教学场景里根本跑不起来——老师没法演示学生没法复现连课程助教都说不清实验环境怎么搭。云计算课件的核心矛盾在于它既要讲清楚分布式资源池化、虚拟化调度、弹性伸缩这些抽象概念又要让学习者在有限课时内亲手触碰真实系统。这意味着课件不能只是静态的 PPT 或 PDF而应该是一套“可执行的教学单元”——每个知识点都对应一段能跑的命令、一个能观察的现象、一组能调参的变量。适合读这篇笔记的人有三类正在开发云计算课程的高校教师、需要给团队做内部培训的架构师、以及想通过动手实验真正理解云底层机制的自学者。接下来我会按“先立概念框架、再搭最小实验、最后调优排错”的路径把一套能落地的云计算课件方案拆开讲。2. 云计算课件的知识骨架先定实验边界再选技术栈2.1 为什么课件要先画“能力矩阵”而不是“知识图谱”知识图谱解决的是“先学什么后学什么”但云计算课件面临的实际约束是实验室机器够不够、网络能不能隔离、学生账号怎么管理。我一般会先画一张能力矩阵横轴是课程模块虚拟化、容器、对象存储、负载均衡、监控纵轴是能力层级能描述、能配置、能排错、能设计。每个交叉点标注所需的最小资源CPU 核数、内存、磁盘、是否需要多节点。这张矩阵直接决定技术选型。比如“能配置”层级只需要单机跑 KVM 或 Docker“能排错”层级就需要至少三节点集群来观察网络分区和调度失败。很多课件翻车就是因为选了太重的基础设施——一上来就上 OpenStack 全栈结果学生光等环境就耗掉半节课。常见做法是前 4 课时用单机容器讲资源隔离中间 6 课时用轻量编排工具讲调度最后 4 课时用模拟故障注入讲高可用。提示能力矩阵里的“能排错”一列必须对应可注入的故障场景否则课件就退化成配置手册。2.2 用 Docker Compose 搭一个“最小云环境”的实操步骤下面这段 Compose 文件定义了一个包含计算节点模拟器、对象存储和监控面板的最小环境。它不依赖任何云厂商全部跑在本地 Docker 里适合作为课件第一个实验的起点。# docker-compose.yml version: 3.8 services: # 模拟计算节点用 cgroup 限制 CPU 和内存 compute-node: image: alpine:3.19 command: sh -c while true; do sleep 3600; done deploy: resources: limits: cpus: 0.5 # 限制 0.5 核观察调度影响 memory: 256M # 限制内存触发 OOM 时讲解弹性伸缩 networks: - cloud-lab # 模拟对象存储MinIO 单节点 object-store: image: minio/minio:latest command: server /data --console-address :9001 environment: MINIO_ROOT_USER: admin MINIO_ROOT_PASSWORD: password123 volumes: - ./minio-data:/data ports: - 9000:9000 - 9001:9001 networks: - cloud-lab # 监控面板Prometheus Grafana 精简版 monitor: image: prom/prometheus:latest volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml ports: - 9090:9090 networks: - cloud-lab networks: cloud-lab: driver: bridge逻辑说明compute-node用deploy.resources.limits模拟云主机的资源配额学生可以通过docker stats观察限制生效后的表现。object-store提供 S3 兼容接口后续课件可以让学生用awscli或boto3上传下载文件理解对象存储的扁平命名空间。monitor采集容器指标用来讲解监控数据模型。参数说明cpus: 0.5表示最多使用半个 CPU 核心适合演示“超卖”场景memory: 256M是硬限制超过会触发 OOM Killer正好用来讲弹性伸缩的触发条件。MinIO 的MINIO_ROOT_USER和MINIO_ROOT_PASSWORD在课件里要改成学生自己学号后四位避免多人共用时冲突。启动命令docker compose up -d docker compose ps # 确认三个服务都是 running docker stats --no-stream # 查看 compute-node 的资源占用如果docker stats里compute-node的 MEM USAGE 接近 256M 但没被 kill说明限制没生效检查 Docker 是否启用了 cgroup v2。2.3 课件里必须讲清的三个“看不见的机制”第一个是命名空间隔离。学生用docker exec进入容器后ps aux只能看到自己的进程这就是 PID namespace 的效果。课件里可以让学生对比宿主机和容器内的ps输出直观感受隔离边界。第二个是 cgroup 配额。上面 Compose 文件里的cpus和memory最终会写到/sys/fs/cgroup/下对应路径。让学生cat /sys/fs/cgroup/cpu.max看到50000 100000这样的数值比讲十页调度算法都管用。第三个是 overlay 文件系统。容器镜像分层存储docker history能看到每一层的来源。课件里可以让学生修改容器内文件后docker diff查看变更层理解“写时复制”如何影响启动速度和磁盘占用。这三个机制是后续讲 Kubernetes 调度、Serverless 冷启动、云盘性能的基石。如果课件跳过它们直接讲 API 和 YAML学生遇到“Pod 一直 Pending”或“容器启动慢”时就会完全懵掉。3. 把抽象概念变成可观测实验四个必做的课堂演示3.1 用 stress-ng 触发 CPU 限额并观察调度延迟在compute-node容器里安装stress-ng然后跑满 CPU同时用time命令测量一个简单操作的耗时变化。# 进入计算节点容器 docker exec -it compute-node容器ID sh # 安装压力测试工具 apk add stress-ng # 后台启动 2 个 CPU 压力进程容器限制 0.5 核必然争抢 stress-ng --cpu 2 --timeout 60s # 测量一个简单命令的延迟 time ls /usr/bin /dev/null逻辑说明容器被限制为 0.5 核但stress-ng启动了 2 个 workerCPU 时间片被严重争抢。time ls的 real 时间会明显大于 usersys 时间说明进程在等待调度。这个实验让学生亲眼看到“资源配额”不是纸面数字而是直接影响响应延迟的硬约束。参数说明--cpu 2表示启动 2 个 CPU 压力进程--timeout 60s让压力持续 60 秒方便学生在窗口期内反复测量。如果课件课时紧张可以改成--timeout 30s。3.2 用 tc 模拟网络延迟观察分布式共识超时云计算课件绕不开 CAP 理论和共识算法但直接讲 Raft 太抽象。我一般会在两个容器之间用tc注入延迟然后让学生观察一个简单的键值存储比如 etcd 单节点的写入超时。# 在 compute-node 容器里安装 iproute2 apk add iproute2 # 给 eth0 网卡注入 200ms 延迟 tc qdisc add dev eth0 root netem delay 200ms # 测试到 object-store 的延迟 ping -c 3 object-store # 清除延迟规则 tc qdisc del dev eth0 root逻辑说明tc qdisc add在网卡队列规则里插入netem模块模拟广域网延迟。学生可以看到ping的 RTT 从 1ms 跳到 200ms 以上。如果课件里有一个依赖心跳的演示服务此时会观察到心跳超时、主从切换等现象。参数说明delay 200ms可以改成delay 100ms 50ms表示 100ms 基础延迟加 50ms 抖动更接近真实跨可用区网络。tc qdisc del是后悔药实验结束必须执行否则后续实验会一直被延迟干扰。3.3 用 MinIO 版本控制演示对象存储的“不可变性”对象存储和文件系统最大的区别是版本控制和生命周期管理。MinIO 支持桶版本控制课件里可以让学生上传同名文件多次然后列出所有版本。# 在宿主机安装 awscli或使用 python boto3 pip install awscli # 配置 MinIO 凭证 aws configure set aws_access_key_id admin aws configure set aws_secret_access_key password123 aws configure set default.region us-east-1 # 创建桶并开启版本控制 aws --endpoint-url http://localhost:9000 s3 mb s3://course-bucket aws --endpoint-url http://localhost:9000 s3api put-bucket-versioning \ --bucket course-bucket \ --versioning-configuration StatusEnabled # 上传同名文件三次 echo version 1 file.txt aws --endpoint-url http://localhost:9000 s3 cp file.txt s3://course-bucket/ echo version 2 file.txt aws --endpoint-url http://localhost:9000 s3 cp file.txt s3://course-bucket/ echo version 3 file.txt aws --endpoint-url http://localhost:9000 s3 cp file.txt s3://course-bucket/ # 列出所有版本 aws --endpoint-url http://localhost:9000 s3api list-object-versions \ --bucket course-bucket --prefix file.txt逻辑说明每次上传都会生成新的 VersionId旧版本不会被覆盖。学生可以下载指定版本验证“对象存储的删除只是打标记”这一关键特性。这个实验直接对应云厂商的对象存储生命周期规则和跨区域复制配置。参数说明--endpoint-url指向本地 MinIO如果课件部署在远程实验机改成对应 IP。--prefix file.txt限定只列出该文件的版本避免输出过长。3.4 用 Prometheus 查询语言讲清“监控指标的时间序列模型”监控是云计算的“黑匣子”但很多课件只教怎么装 Grafana不教怎么查数据。我一般会让学生直接在 Prometheus 的 HTTP API 里执行 PromQL观察容器 CPU 使用率的原始时间序列。# 查询 compute-node 容器最近 5 分钟的 CPU 使用率 curl -s http://localhost:9090/api/v1/query_range \ --data-urlencode queryrate(container_cpu_usage_seconds_total{namecompute-node}[1m]) \ --data-urlencode start2025-01-01T00:00:00Z \ --data-urlencode end2025-01-01T00:05:00Z \ --data-urlencode step15s | python -m json.tool逻辑说明rate()计算每秒增量[1m]是滑动窗口step15s是采样间隔。返回的 JSON 里每个时间点对应一个数值这就是时间序列数据库的基本存储单元。学生可以把这个结果和docker stats的实时输出对比理解“瞬时值”和“区间速率”的区别。参数说明start和end要改成实验当天的实际时间。step越小曲线越精细但查询开销越大课件里可以让学生分别用15s和60s查询对比返回点数。4. 避坑与排查云计算课件开发中最容易翻车的五个地方4.1 实验环境“一次能跑”不等于“每次能跑”现象第一次上课所有学生都能启动容器第二次上课有三分之一的人报端口冲突或镜像拉取失败。原因Docker 端口映射是全局的多个学生共用一台实验机时 9000、9001、9090 这些端口会被抢占。另外镜像没有预拉取教室网络一拥而上时 registry 限流。解决课件里所有端口改成从环境变量读取每个学生分配独立端口段。镜像提前docker save成 tar 文件放在本地用docker load导入。Compose 文件里加pull_policy: never强制使用本地镜像。4.2 资源限制设得太死导致实验“卡死”现象学生按课件设置memory: 128M后容器里的apk add直接 OOM连 shell 都进不去。原因Alpine 基础镜像本身占用约 50M加上包管理器的临时文件128M 在安装软件时必然溢出。解决课件里区分“运行态限制”和“安装态限制”。安装软件时用docker exec临时放宽或者把常用工具预装到自定义镜像里。Compose 文件里内存限制至少给 256M并在注释里写明“这是运行态下限安装软件时请临时调整”。4.3 tc 延迟规则忘记清除导致后续实验全乱现象学生做完网络延迟实验后下一个实验里所有服务心跳都超时但ping又正常。原因tc qdisc规则挂在网卡上容器重启不会自动清除除非删除容器重建。解决课件里每个网络实验的最后一步必须是tc qdisc del dev eth0 root并且加一个检查命令tc qdisc show dev eth0确认输出只有noqueue或pfifo_fast。如果学生忘记助教用docker restart重建容器。4.4 MinIO 版本控制开启后磁盘暴涨现象学生反复上传同一个大文件做实验实验机磁盘两天就满了。原因版本控制保留所有历史版本删除操作只是打删除标记实际数据仍在。解决课件里加一个清理步骤用aws s3api delete-objects指定 VersionId 彻底删除或者直接docker compose down -v清空数据卷。同时把实验文件大小限制在 1MB 以内避免单个学生占用过多空间。4.5 Prometheus 查询时间范围写死导致“查不到数据”现象学生复制课件里的curl命令返回空结果。原因课件里的start和end是写死的示例时间学生实验时已经过了那个时间段。解决课件里用 shell 变量动态生成时间范围例如start$(date -u -d 5 minutes ago %Y-%m-%dT%H:%M:%SZ)让学生直接复制整段脚本执行。同时提醒学生检查 Prometheus 的--storage.tsdb.retention.time参数默认 15 天如果实验机时间不对也会查不到。5. 让课件“活”过一学期版本化实验脚本与自动化验证5.1 用 Makefile 把零散命令收成一条入口课件里的命令一旦超过 20 条学生就会漏步骤。我习惯给每个实验写一个 Makefile把docker compose up、stress-ng、tc、aws s3 cp这些操作封装成make demo-cpu、make demo-network这样的目标。学生只需要make demo-cpu就能跑完整个演示减少手误。# Makefile .PHONY: up down demo-cpu demo-network demo-storage clean up: docker compose up -d echo 等待服务就绪... sleep 5 demo-cpu: up docker exec compute-node apk add stress-ng docker exec compute-node sh -c stress-ng --cpu 2 --timeout 30s echo 观察 docker stats 中 compute-node 的 CPU 占用 demo-network: up docker exec compute-node apk add iproute2 docker exec compute-node tc qdisc add dev eth0 root netem delay 200ms echo 现在 ping object-store 会看到 200ms 延迟 echo 清除规则请执行: make clean-network clean-network: docker exec compute-node tc qdisc del dev eth0 root || true down: docker compose down -v clean: down rm -rf minio-data逻辑说明make demo-cpu依赖up确保服务先启动。|| true让clean-network在规则不存在时也不报错。clean目标清空所有数据卷和本地 MinIO 数据适合每节课后重置环境。参数说明sleep 5是等待 MinIO 和 Prometheus 初始化如果实验机性能差可以改成sleep 10。stress-ng --timeout 30s把压力时间缩短到 30 秒避免占用太多课堂时间。5.2 用 pytest 写“课件自检”脚本课件交付前我会写一组 pytest 用例自动验证每个实验的关键现象是否出现。比如验证 CPU 限制生效、验证 MinIO 版本控制返回多个 VersionId、验证 Prometheus 能查到数据。这样每次修改课件后跑一遍pytest就能知道有没有改坏。# test_courseware.py import subprocess import json import pytest def test_cpu_limit(): 验证 compute-node 的 CPU 限制生效 result subprocess.run( [docker, stats, --no-stream, --format, {{.CPUPerc}}, compute-node], capture_outputTrue, textTrue ) cpu_percent float(result.stdout.strip().rstrip(%)) # 限制 0.5 核空闲时应该远低于 50% assert cpu_percent 50, fCPU 占用 {cpu_percent}% 超过限制 def test_minio_versioning(): 验证 MinIO 版本控制返回多个版本 result subprocess.run( [aws, --endpoint-url, http://localhost:9000, s3api, list-object-versions, --bucket, course-bucket, --prefix, file.txt], capture_outputTrue, textTrue ) data json.loads(result.stdout) versions data.get(Versions, []) assert len(versions) 3, f期望至少 3 个版本实际 {len(versions)} def test_prometheus_query(): 验证 Prometheus 能查到容器指标 result subprocess.run( [curl, -s, http://localhost:9090/api/v1/query, --data-urlencode, querycontainer_cpu_usage_seconds_total{namecompute-node}], capture_outputTrue, textTrue ) data json.loads(result.stdout) assert data[status] success assert len(data[data][result]) 0, 未查到 compute-node 指标逻辑说明test_cpu_limit用docker stats的格式化输出提取 CPU 百分比断言低于 50%。test_minio_versioning调用 S3 API 列出对象版本断言至少 3 个。test_prometheus_query直接查 Prometheus HTTP API确认指标存在。这三个用例覆盖了课件最核心的三个实验。参数说明--format {{.CPUPerc}}是 Docker 的 Go 模板语法只输出 CPU 百分比。--data-urlencode确保 PromQL 里的花括号和引号被正确编码。如果实验机没有安装awscli可以用boto3替代。5.3 课件版本化用 Git 标签对应课时最后一个习惯每节课的课件状态打一个 Git 标签比如lesson-01、lesson-02。学生如果中途环境乱了可以git checkout lesson-01回到第一节课的初始状态。Makefile 和 pytest 脚本也一起提交助教用make clean make up就能重置整个实验环境。我自己的血泪经验是云计算课件最大的成本不是写内容而是维护实验环境的可复现性。一旦环境漂移再好的讲解都会变成玄学。把环境定义、操作入口、自检脚本全部代码化课件才能活过一学期。希望帮到你。本文还有配套的精品资源点击获取
