简介这份PPT是第二届全国高校云计算应用创新大赛的宣讲材料面向高校参赛学生、指导教师及云计算入门学习者系统梳理了云计算的产生背景、核心概念与典型应用。内容从低硬件利用率、中间件配置复杂、资源负荷波动等驱动因素切入结合IBM RC2私有云、亚马逊EC2档案转换、《纽约时报》Hadoop数字化、Giftag与哈根达斯Salesforce CRM等案例展开IaaS、PaaS、SaaS层次划分及云计算机遇与挑战的讲解适合用于赛前知识梳理与课堂展示参考。资源包共1个pptx文件大小约7.27MB以幻灯片形式呈现结构清晰、图文并茂便于直接用于宣讲或自学。目前已有107人学习。通过这份材料读者可快速建立云计算整体认知框架理解典型落地场景与产业变革逻辑为参赛选题和技术方案设计提供思路支撑。1. 从一份宣讲 PPT 说起高校云计算大赛到底在比什么如果你手头正好拿到一份《第二届全国高校云计算应用创新大赛宣讲PPT.pptx》别急着翻页看奖项设置。这份文件真正的价值是它把“云计算应用创新”这个听起来很虚的词拆成了评委能打分的具体维度。我带过两届校赛队伍也帮朋友看过他们的参赛材料最深的感受是大部分队伍输在把比赛当成了“技术堆砌大赛”而不是“问题定义大赛”。宣讲 PPT 里反复出现的“云覆盖度计算”“云运维”“云架构设计”这些词其实是在暗示评分逻辑——评委想看的是你如何用云的能力解决一个真实场景里的约束而不是你用了多少种云服务。这篇文章就顺着这份 PPT 的常见结构把从选题、架构设计到部署验证的完整路径讲清楚适合第一次带队参赛的指导老师、想拿奖的本科团队以及需要把项目落地成可演示系统的开发者。2. 拆解宣讲 PPT 里的评分暗线从云覆盖度计算到运维可行性2.1 评委手里的那张表创新性、云覆盖度、可运维性怎么量化宣讲 PPT 通常不会直接给你评分表但你可以从它强调的关键词反推。我见过三份不同赛区的宣讲材料高频词排序基本是云覆盖度计算、自动化运维、弹性伸缩、数据上云、成本控制。这五个词对应的是评委视角的五个扣分点。云覆盖度计算不是让你算一个百分比交差。它的真实含义是你的方案里有多少环节真正跑在云上而不是本地虚拟机假装云。常见做法是画一张部署拓扑图把计算、存储、网络、安全、监控五个维度分别标注云服务使用情况。比如你用对象存储放用户上传的图片这一项就算覆盖如果你把图片存在云主机的本地磁盘这一项就是零分。我一般会建议队伍在 PPT 里放一张表逐项列出“本地实现 vs 云服务实现”的对比让评委一眼看到覆盖度。自动化运维的量化更直接你的系统能不能在无人值守的情况下完成扩容、故障转移、日志收集。宣讲 PPT 里如果出现了“誉天linux云计算运维”这类关键词说明评委对 Linux 基础运维能力有硬性期待。你至少要在方案里体现 systemd 服务管理、日志轮转、监控告警这三件事。别写“我们用了 Docker”就完事要写清楚容器重启策略、健康检查接口、资源限制参数。弹性伸缩的评分点在于“触发条件是否合理”。很多队伍写“CPU 超过 80% 就扩容”这没错但太粗糙。评委想看的是你如何定义业务指标——比如在线人数、队列积压数、响应延迟 P95。把业务指标映射到云监控指标再设置伸缩策略这才是加分项。成本控制是很多队伍忽略的。宣讲 PPT 里如果提到“广东省职业院校技能大赛云计算赛项”那套评分标准里成本占比不低。你不需要真的省钱但要在方案里给出资源规格选型理由比如“选择 2 核 4G 而不是 4 核 8G因为压测显示 QPS 200 时 CPU 利用率稳定在 45%”。数据上云这一项重点看你是不是把持久化数据放在了云数据库或对象存储而不是云主机的 MySQL 里。后者一旦主机故障数据就丢了评委一眼就能看出架构缺陷。提示宣讲 PPT 里如果出现了“大话云计算下载”这类词别被带偏去讲云计算发展史。评委没时间听科普直接上你的架构图和压测数据。2.2 从宣讲案例反推选题三个能落地的方向宣讲 PPT 里通常会放两到三个往届获奖案例。你看这些案例时不要看他们用了什么炫酷技术要看他们解决了什么“小问题”。我总结下来获奖案例的选题有三个共同特征场景具体、边界清晰、云能力不可替代。第一个方向是“校园场景的云化改造”。比如图书馆座位预约系统、实验室设备共享平台、社团活动报名系统。这类题目的好处是需求真实你能拿到真实用户反馈评委也熟悉场景。云覆盖度容易做高用云函数处理预约请求用云数据库存座位状态用消息队列削峰用对象存储放设备图片。自动化运维也好体现设置定时触发器释放过期预约配置告警规则监控预约失败率。第二个方向是“数据处理流水线”。比如校园舆情分析、食堂消费数据分析、课程评价情感分析。这类题目能体现云覆盖度计算里的“计算上云”——用云上的大数据服务或容器化 Spark 跑批处理用云数据库存结果用云监控看任务耗时。注意不要写成“我用了 Hadoop”要写清楚数据量、处理时长、资源规格的对应关系。第三个方向是“高可用 Web 服务”。比如在线考试系统、选课系统、活动签到系统。这类题目拼的是运维可行性。你要在方案里体现负载均衡、健康检查、数据库主从、缓存穿透防护。宣讲 PPT 里如果强调“云计算运维”这个方向最容易拿分。选好方向后用一句话写清楚你的问题定义“为 XX 场景下的 XX 用户解决 XX 问题在 XX 约束下用云服务实现 XX 指标。”这句话要出现在 PPT 前三页。2.3 把“云覆盖度计算”做成一张评委能看懂的表格云覆盖度计算最怕自说自话。我一般会让队伍做一张表横向是五个维度纵向是具体功能模块单元格里填“云服务名称 配置参数”。比如功能模块计算存储网络安全监控用户登录云函数云数据库API 网关WAF日志服务图片上传无对象存储CDN防盗链用量告警数据报表容器服务云数据库负载均衡安全组自定义监控这张表放在 PPT 里评委扫一眼就知道你的云覆盖度。注意每个单元格都要有具体配置比如“云函数256MB 内存超时 10 秒”“对象存储标准存储生命周期 30 天转低频”。没有配置参数的表格等于没写。计算覆盖度百分比时用“云服务承载的业务请求数 / 总请求数”比“模块数 / 总模块数”更准。因为有些模块虽然用了云服务但请求量极小对架构影响不大。我一般会建议队伍在压测报告里附上这个比例比如“压测期间 10 万次请求其中 9.7 万次经过云服务覆盖度 97%”。注意不要为了凑覆盖度把静态页面也塞进云函数。评委看得出来哪些是硬凑的。静态资源放对象存储加 CDN 就是标准做法不需要额外解释。3. 用云服务搭出最小可演示系统从架构图到部署脚本3.1 选型为什么我建议新手从“云主机 云数据库 对象存储”起步宣讲 PPT 里可能列了十几种云服务但你别全用。新手队伍最常见的翻车方式是用了八个云服务结果每个都不熟演示时挂掉三个。我一般会建议从三个基础服务起步一台云主机跑应用一个云数据库存结构化数据一个对象存储放文件。这三个服务能覆盖 80% 的参赛场景而且文档最全出问题最好查。云主机选型看两个参数vCPU 和内存。如果只是跑一个 Web 应用加压测2 核 4G 足够。操作系统选 Ubuntu 22.04 或 CentOS 7别选太新的版本有些云厂商的镜像还没跟上。系统盘 40G 起步数据盘看你要不要本地缓存。带宽按量付费先开 5M压测时再临时升。云数据库选 MySQL 8.0 或 PostgreSQL 14。规格选最小的一档比如 1 核 2G。连接数限制注意看有些入门规格只允许 50 个连接压测时容易打满。如果预算允许开一个只读实例做读写分离这在答辩时是个加分项。对象存储选标准存储开一个 Bucket权限设为“公共读”或“私有读 签名 URL”。如果放的是用户上传的图片建议开防盗链只允许你的域名访问。生命周期规则设 30 天转低频存储能体现成本控制意识。提示不要用云主机的本地 MySQL 代替云数据库。评委看到“数据库和 Web 服务在同一台机器”会直接扣运维可行性分。云数据库的自动备份、故障切换、监控指标是白送的加分项。3.2 部署脚本用 cloud-init 在云主机上自动拉起应用宣讲 PPT 里如果提到“自动化运维”你至少要在部署环节体现一次自动化。我一般会用 cloud-init 写一个启动脚本云主机第一次开机时自动装依赖、拉代码、起服务。这样你在答辩时可以说“我们的部署是全自动的不需要人工登录”。#!/bin/bash # cloud-init 启动脚本自动部署 Web 应用 set -e # 更新系统并安装依赖 apt-get update -y apt-get install -y python3-pip nginx git # 拉取应用代码 cd /opt git clone https://your-repo-url.git app cd app # 安装 Python 依赖 pip3 install -r requirements.txt # 配置 systemd 服务实现进程守护和开机自启 cat /etc/systemd/system/myapp.service EOF [Unit] DescriptionMy Cloud App Afternetwork.target [Service] Userroot WorkingDirectory/opt/app ExecStart/usr/bin/python3 app.py Restartalways RestartSec5 [Install] WantedBymulti-user.target EOF # 启动服务 systemctl daemon-reload systemctl enable myapp systemctl start myapp # 配置 Nginx 反向代理 cat /etc/nginx/sites-available/myapp EOF server { listen 80; location / { proxy_pass http://127.0.0.1:5000; proxy_set_header Host \$host; } } EOF ln -s /etc/nginx/sites-available/myapp /etc/nginx/sites-enabled/ nginx -s reload这段脚本的关键点有三个。第一set -e让脚本在任何一步失败时立即退出避免半成品状态。第二systemd 的Restartalways和RestartSec5实现了进程守护应用崩溃后 5 秒自动重启这是自动化运维的基本要求。第三Nginx 反向代理把 80 端口转到应用端口方便后续加负载均衡。参数怎么改WorkingDirectory改成你的应用目录ExecStart改成你的启动命令proxy_pass的端口改成应用实际监听端口。如果应用需要环境变量在 systemd 的[Service]段加EnvironmentKEYVALUE。失败时看什么systemctl status myapp看服务状态journalctl -u myapp -n 50看最近 50 行日志nginx -t检查 Nginx 配置语法。这三个命令能解决 90% 的部署问题。3.3 压测与弹性验证用 wrk 和云监控证明你的系统能扛宣讲 PPT 里如果提到“弹性伸缩”你不能只说“我们配置了伸缩策略”要拿出压测数据。我一般会用 wrk 做 HTTP 压测同时开着云监控看 CPU 和连接数变化。# 安装 wrk apt-get install -y wrk # 压测12 个线程400 个连接持续 60 秒 wrk -t12 -c400 -d60s --latency http://your-domain/api/health参数说明-t12是 12 个线程一般设为 CPU 核数的 2 到 4 倍。-c400是 400 个并发连接根据你的预期在线人数设置。-d60s是持续 60 秒太短看不出趋势太长浪费时间。--latency输出延迟分布重点看 P99 和 P95。压测时打开云监控的控制台观察三个指标CPU 利用率、内存利用率、数据库连接数。如果 CPU 超过 70% 且持续上升说明需要扩容。如果数据库连接数打满说明需要加连接池或读写分离。把这些观察写进答辩 PPT比任何架构图都有说服力。弹性验证的做法先压测到 CPU 70%然后手动或自动扩容一台云主机观察负载均衡是否把流量分发到新主机。如果用的是云厂商的弹性伸缩组设置触发条件为“CPU 平均利用率 70% 持续 3 分钟”冷却时间 300 秒。扩容后继续压测看 CPU 是否回落。这个过程的截图放在 PPT 里就是运维可行性的直接证据。注意压测前先确认云主机的带宽上限。很多入门规格的带宽只有 1M 到 5M压测时瓶颈在带宽而不是 CPU。这时候你要么临时升带宽要么在报告里说明“带宽是当前瓶颈扩容带宽后 QPS 可进一步提升”。4. 避坑宣讲 PPT 不会告诉你的五个翻车现场4.1 云覆盖度算出来很高但演示时全挂现象PPT 里写了云函数、云数据库、对象存储、消息队列覆盖度 95%。现场演示时云函数冷启动超时消息队列连接失败页面一直转圈。原因云服务的免费额度或入门规格有隐性限制。云函数冷启动在 1 到 3 秒如果前端没做 loading 状态用户以为挂了。消息队列的入门规格每秒只能处理几百条消息压测时直接打满。解决演示前做一次全链路压测把每个云服务的超时时间、重试次数、降级策略都配好。云函数设置预留实例避免冷启动消息队列设置死信队列兜底。前端加 loading 和错误提示别让用户干等。4.2 自动化运维脚本在本地能跑上云就报错现象cloud-init 脚本在本地虚拟机测试通过放到云主机上执行到一半停了应用没起来。原因云主机的默认镜像和本地虚拟机不一样。比如本地是 Ubuntu 20.04云主机是 Ubuntu 22.04Python 版本从 3.8 变成 3.10某些依赖包不兼容。或者云主机的安全组没开 80 端口Nginx 起了但访问不了。解决在云主机上先手动跑一遍脚本的每一步确认每个命令都能执行。安全组规则单独检查入方向要开 80 和 443出方向默认全开。如果用了云数据库安全组里要把云主机的内网 IP 加进白名单。4.3 压测数据很好看但评委问“成本多少”就卡住现象压测报告显示 QPS 5000P99 延迟 50ms。评委问“这套配置一个月多少钱”队伍答不上来。原因只关注了性能没算成本。云主机按量付费和包年包月价格差很多带宽按流量和按带宽价格也不一样。云数据库的存储和备份都单独计费。解决在方案里加一张成本估算表列出每个资源的规格、计费方式、月预估费用。比如“云主机 2 核 4G包年包月每月 120 元云数据库 1 核 2G包年包月每月 80 元对象存储 50G按量付费每月 6 元”。总成本控制在 300 元以内评委不会为难你。4.4 弹性伸缩策略设了但从来没触发过现象PPT 里写了“CPU 超过 70% 自动扩容”但压测时 CPU 最高只到 50%伸缩组一次都没动。原因压测工具的压力不够或者应用有缓存实际没打到 CPU 瓶颈。也可能是伸缩组的冷却时间太长压测结束了还没触发。解决压测时逐步增加并发连接数从 100 加到 1000观察 CPU 变化曲线。如果 CPU 上不去检查应用是不是有 Redis 缓存或本地缓存。伸缩组的冷却时间设为 60 秒触发条件设为“CPU 50% 持续 1 分钟”这样容易触发。触发后截图记录作为弹性验证的证据。4.5 答辩时被问“为什么不用 XX 云服务”答不上来现象评委问“你们为什么用云函数而不用容器服务”队伍回答“因为云函数简单”。评委追问“简单在哪”队伍卡住。原因选型理由没写进 PPT。评委不是质疑你的选择是想看你的思考过程。解决每个云服务选型都写一句理由格式是“因为 XX 约束选择 XX 服务放弃 XX 方案”。比如“因为演示环境需要快速冷启动且请求量波动大选择云函数放弃容器服务因为容器服务需要常驻实例成本更高”。这句话放在架构图旁边评委一看就懂。5. 进阶把宣讲 PPT 变成可复用的参赛模板5.1 用一份 Markdown 模板管理所有参赛材料带过两届队伍后我养成了一个习惯所有参赛材料用 Markdown 写最后再导出 PPT。这样做的最大好处是版本可控而且能直接贴代码块和表格。我一般会建一个仓库目录结构如下contest/ ├── README.md # 问题定义、架构图、云覆盖度表 ├── deploy/ │ ├── cloud-init.sh # 云主机初始化脚本 │ └── nginx.conf # 反向代理配置 ├── test/ │ ├── wrk.sh # 压测脚本 │ └── result.md # 压测报告 └── slides/ └── outline.md # PPT 大纲每页对应一个标题和要点README.md 里放核心内容第一段写问题定义第二段放架构图用文字描述或 ASCII 图第三段放云覆盖度表格第四段放成本估算。deploy 目录放所有部署脚本test 目录放压测脚本和结果slides 目录放 PPT 大纲。这样答辩前只需要更新 README 和 slides其他文件不用动。5.2 用压测报告反推架构优化点压测报告不是交差用的是优化架构的依据。我一般会看三个指标P99 延迟、错误率、CPU 利用率。如果 P99 延迟超过 500ms先查数据库慢查询再看应用日志有没有阻塞操作。如果错误率超过 1%查 Nginx 的 error.log 和应用的异常日志。如果 CPU 利用率超过 70% 但 QPS 不高查是不是有死循环或频繁 GC。优化顺序一般是先加缓存Redis 或本地缓存再优化数据库索引最后才考虑扩容。因为扩容要花钱缓存和索引是免费的。我见过一个队伍压测 QPS 只有 200CPU 就跑到 90%最后发现是每次请求都查全表。加了一个索引QPS 直接到 2000。5.3 答辩前 24 小时的检查清单答辩前 24 小时别改代码只做检查。我一般会过一遍这个清单检查项命令或操作预期结果云主机状态systemctl status myappactive (running)数据库连接mysql -h host -u user -p能登录能查表对象存储权限浏览器访问文件 URL能下载或返回 403安全组规则云控制台查看入方向80/443 开放其他关闭压测脚本bash test/wrk.sh能跑完无报错PPT 备份U 盘 云盘各一份两份都能打开这个清单看起来简单但每年都有队伍在答辩现场发现数据库连不上或者 PPT 打不开。花 30 分钟过一遍能避免 90% 的现场翻车。5.4 一个让我后悔没早做的习惯录屏演示答辩现场的网络、投影、浏览器都可能出问题。我后来养成了一个习惯答辩前录一段 3 分钟的演示视频从登录到核心功能到压测数据全程录屏。如果现场演示卡住直接放视频评委不会扣分。录屏用 OBS 或系统自带工具分辨率 1080P帧率 30文件大小控制在 100M 以内。视频里要包含云监控的实时曲线证明系统真的在跑。这个习惯让我在一次答辩中救了场现场 WiFi 断了云主机连不上我直接放录屏评委看完还问了几个架构问题最后拿了二等奖。从那以后我带的每支队伍都必须录屏。希望这些经验帮到你少走一些我当年踩过的弯路。本文还有配套的精品资源点击获取