云计算作业实战：高可用Web应用部署从规划到落地

上周帮一个学弟看他的云计算课程大作业，题目是"基于公有云平台设计并部署一个高可用Web应用"。他卡在负载均衡的健康检查上整整两天，后端服务器一直在"不健康"和"健康"之间反复横跳，网站时好时坏。我远程连上去一看，安全组只放通了80端口，健康检查的8080端口根本没开——这种低级问题，放到生产环境就是一次线上事故。

这篇内容不打算像教科书那样从云计算定义讲起。既然标题是"云计算作业"，那就按作业的完整链路来：怎么把一道模糊的题目拆成可落地的方案、资源怎么规划不踩坑、核心功能怎么实现、作业之外怎么加运维加分项、最后怎么把这次作业变成面试时能讲的实战项目。全文内容基于一次完整的课程作业实践记录，凡是涉及产品功能和参数的地方，均以主流公有云平台的通用能力为准，你自己用的云厂商不同，按对应控制台的命名和入口稍作调整即可。

我先把这次作业的核心信息交代清楚，方便你对照。

• 作业题目：基于公有云平台设计并部署一个高可用Web应用
• 基本要求：应用需跨两个可用区部署，任一可用区故障时服务不中断；使用负载均衡分发流量；静态资源使用对象存储；配置基本的监控告警
• 交付物：架构图、部署文档、访问测试报告、答辩PPT

听上去不复杂对吧？但真正动手做的时候，你会发现"高可用"这三个字背后牵扯出一大堆东西：网络规划、安全组、子网划分、存储桶权限、健康检查、会话保持、监控指标选取、故障模拟验证……任何一个环节想当然，作业就翻车。下面我按实际完成作业的顺序拆开讲，这些坑你大概率也会遇到。

1. 需求拆解：把"高可用"这道题翻译成云资源清单

拿到这种大作业，最容易犯的错就是直接打开控制台开两台服务器，配个负载均衡就算完事。这么做表面上能跑通，但答辩时老师随便问一句"你的高可用体现在哪里"就露馅了。正确做法是先把题目里的关键词全部翻译成云平台的资源。

1.1 需求分析的四个关键维度

"高可用Web应用"这句话可以拆成关注点：对外提供什么服务、流量怎么进来、后端怎么扛住故障、数据存在哪里。每一块对应到云资源就是一条链路。

第一，对外服务。需要一个公网入口，这个入口不能是某台服务器的公网IP直接暴露，否则这台机器挂了入口就没了。所以要用负载均衡服务，它本身有冗余机制，公网IP挂在负载均衡上，后端服务器健康检查通过才转发流量。

第二，后端计算资源。至少两台云服务器，放在不同的可用区。可用区是物理上独立的数据中心，电力、网络都隔离，一台挂了另一台不受影响。这里注意，题目说的是"高可用"，不是"高性能"，所以架构上要的是冗余，不是扩容。

第三，静态资源存储。图片、CSS、JS这些静态文件不能放在应用服务器本地磁盘。原因有两个：一是本地磁盘空间有限且没有冗余，二是多台服务器如果各自存一份，更新时还要逐台同步，非常痛苦。放对象存储里，天然就是多副本冗余，还能配合CDN加速。

第四，数据和状态。如果应用有用户登录、订单等动态数据，就得用云数据库，不能写在服务器本地。这是很多作业最容易漏的点——本地部署MySQL，然后被老师问"数据库单点故障了怎么高可用"。

1.2 选型时最容易纠结的几个点

我实际操作下来，选型这部分有几个地方特别容易反复纠结。

云服务器规格到底选多大？作业场景选最小规格就够了，一般2核4G就能跑通，但建议用按量付费而不是包年包月，因为做完测试就要释放，按量付费省成本。不过，如果你的学校有免费额度或者账号本身是试用模式，那就不用考虑这个。

操作系统选哪个？我推荐Ubuntu或者CentOS，主要考量是网上资料多，排查问题时搜到的解决方案最多。你可能会想用Windows Server，但云服务器上Windows镜像更大、启动更慢、资源占用也更高，对云资源操作不熟悉的人会更难排查系统问题。

负载均衡和云服务器的付费方式最好是同一个账号下统一管理，避免出现"资源在不同账号/不同地域下没法直接关联"的尴尬。有一次我见过一个同学在华北区域开了负载均衡，服务器却买在华南，最后只能退掉重买。

1.3 资源清单模板

经过上面分析后，我把作业需要的资源按照需求链路整理成一张清单，这同时也是架构图的素材：

这样从入口到后端再到数据，整条链路的资源全部齐了，架构图也就有了骨架。

2. 网络规划与安全组：作业翻车的第一高发地

如果你问十个做过云上部署的人"最容易在哪个环节踩坑"，至少七个会回答是网络和安全配置。这个环节的问题特征是：资源全都开好了，但就是访问不通，而且控制台上看起来一切正常。

2.1 VPC与子网规划：先画图再动手

VPC的逻辑是给你的资源划出一块私有的网络空间，你可以在里面自己定义网段。对于这个作业来讲，我的建议规划成：VPC网段 10.0.0.0/16，两个交换机子网分别用 10.0.1.0/24 和 10.0.2.0/24。

为什么要建议两个子网放在不同可用区？考虑到可用区故障隔离，资源如果都堆在一个可用区里，那"跨可用区高可用"这个目标就无从谈起了。负载均衡转发流量时，会把请求分发到不同可用区的后端服务器上，所以它们天然需要处于不同子网。

值得注意的是，子网创建之后网段不能修改，所以开始就要想清楚。如果选错了网段，之后只能删掉重建，而VPC里如果还有资源在运行，想删是很麻烦的。我见过有人图省事直接全用完默认网段，后面加了一堆规则搞不清楚哪些是系统默认的、哪些是自己配的，排障时非常头疼。

2.2 安全组规则：一个端口引发的"血案"

回到开头那个学弟的案例：他健康检查失败，就是安全组只放行了80端口。具体来讲，后台服务器的服务其实监听在8080端口，健康检查也访问8080，但安全组规则只放行了80进方向，所以负载均衡发起的探测请求全部被拦在外面。

安全组的本质是云平台的分布式防火墙，可以在实例级别控制进出流量。配置它要考虑两组方向：入方向规则（ingress）—— 别人能不能访问你；出方向规则（egress）—— 你能不能访问外网。默认情况下，出方向全放通，入方向默认拒绝，所以你应该明确入方向要放行哪些来源和端口。

以我这份作业为例，最终安全组规则是这样的：

这里最重要的一个坑在于来源（源地址）的选择。很多教材示例会写0.0.0.0/0，表示所有来源都能访问。如果是负载均衡对后端进行健康检查的端口，来源要尽量限制到负载均衡的网段，而不是全放通，这样安全性更好，也便于在答辩时说明你的安全策略是有考量的。

2.3 专有网络与经典网络的选择

现在主流云平台上都会推荐你使用专有网络，它比经典网络更加安全，且支持自定义网络规划。即便在做作业，我也建议你直接使用专有网络，因为现在普遍支持专有网络的资源种类已经远多于传统方式了。

如果你用的是校园云平台或某云厂商的实训环境，界面可能不太一样，但底层逻辑是一样的：你要有一个隔离网络，里面有子网，然后资源放在子网里，通过安全组控制访问权限。这个概念在阿里云叫专有网络（VPC），在腾讯云叫私有网络（VPC），在AWS叫VPC。名字不完全一致，但你掌握"隔离网络 → 子网划分 → 安全组过滤"这条链路就能顺利应对。

3. 核心功能实现：从控制台操作到跑通服务

资源规划和安全组配好后，接下来就是把每块功能真正落地。这段的重点不是教你每个按钮在哪里点，而是每做一步时你需要理解它为什么是这个逻辑。

3.1 云服务器初始化与Web服务部署

登录云服务器后，第一步不要急着装软件，先把系统源更新一下。以Ubuntu为例：

bash复制sudo apt-get update && sudo apt-get upgrade -y

然后安装Web服务环境。如果你用的是Nginx，可以一条命令装完，还可以顺带把防火墙打开，把当前用户加进sudo组，因为后续装包、改配置大概率会用到：

bash复制sudo apt-get install -y nginx
sudo ufw allow 8080/tcp
sudo systemctl enable nginx && sudo systemctl start nginx

这里有个关键细节：很多作业要求"高可用"，但实际上后端代码只要一份就行，你的部署过程应该让两台服务器保持状态一致。在没有自动化工具（如Ansible）的情况下，手工在每台机器上执行相同命令、拷贝相同代码即可。

部署一个简单的Web应用后，后端服务监听在哪个端口、返回什么内容，需要保持固定。我的做法是让每台后端机器的首页文件内容各自写上本机的主机名或IP，方便之后验证负载均衡是否正确分发流量。

3.2 负载均衡配置：健康检查与转发规则的细节

负载均衡的配置界面一般分两层：监听配置和后端服务器组。监听配置定义的是"外部流量通过什么协议、什么端口进来"，后端服务器组定义的是"流量均匀分发到哪几台机器、以什么方式检查可用性"。

健康检查是这里面最重要的机制。它的大致原理是：负载均衡定期向后端服务器发送探测请求，如果连续多次没有收到预期响应，就把这台服务器从可用服务器组里摘除，不再给它分发新流量，直到它恢复健康。这样能实现故障自动切换，用大白话讲就是：仓库管理员每次发货前先看一眼货架上的东西还在不在，发现某排架子倒了就暂时不从这个方向取货。

我这次作业里，健康检查的推荐配置参考如下：

这里要特别提醒：检查路径不要写成首页根路径 /，因为首页可能包含数据库查询等耗时操作，一旦数据库抖动，健康检查就会误判。我的习惯是单独在服务里加一个 /health 接口，不查数据库，只返回一个200状态码。

另外，负载均衡的转发方式（调度算法）这次作业选了加权轮询。因为两台机器规格一样，权重相同，就是一人一次轮流来。如果你后续想要做灰度发布或者某台机器性能更强，可以调权重。

会话保持的问题：如果你做的应用有用户登录，且登录状态存在本地Session里，那么负载均衡需要开启会话保持（同一客户端IP的请求都分发到同一台后端服务器）。不然用户第一次请求到了A机器，第二次被分到B机器，就要求重新登录。课程作业如果只做页面展示一般用不到，但答辩时可能会被问到，建议在文档里说明你的选择。

3.3 对象存储接入：静态资源分离的常见坑

对象存储在作业里的角色是存放静态文件。简单写法是在控制台创建一个存储桶，然后设置权限、上传文件。

两种常见的访问控制我单独说一下。一种是直接把桶设成公共读，另一种是用API签名的私有读写。作业为了演示方便，我见过很多人直接设公共读，理由是最省事。但如果你在答辩时把"公共读"三个字说出来，很容易被追问"公共读的数据安全怎么保证"。

我的建议是：桶设成私有读写，然后通过后端应用生成带签名的临时链接，或者将对象存储绑定自定义域名并配合CDN来做访问控制。理由和方案可以在答辩文档里说明，这一步能充分体现你对"权限最小化"的理解。

还有跨域问题，前端页面里如果直接用JavaScript调用对象存储的API，会遇到跨域限制，需要为存储桶配置允许的来源域名和请求方法。这个如果不配，页面能打开但图片加载不出来，控制台报CORS错误，排查起来容易蒙圈。

4. 运维视角补课：作业之外的加分项

严格来说，作业只要把前面三节做完、能跑通、文档写好，就能拿到一个不错的分数。但我建议你多往前走半步，把运维的概念也融入进去。因为不管你标题是"云计算作业"还是"云计算运维工程师"，最终都会遇到同样的考验——别人让你保证一个系统持续的稳定运转。控制台里点几下就能创建的"高可用"，只是纸面上的高可用；真正让系统在高负载、异常流量和依赖故障下活下来，才是运维的价值。

4.1 云监控与告警配置

作业要求里写了"配置监控告警"，最基础的就是CPU、内存、磁盘使用率。一般控制台里找到云监控，选择实例，创建告警策略即可。

告警策略需要重点考虑两件事：指标选取和阈值设置。

指标上，除了CPU、内存、磁盘外，我强烈建议加上负载均衡的每秒请求数、后端服务器的健康状态。前者反映流量压力，后者反映可用性。

阈值不要拍脑袋。如果业务正常时段CPU平均20%，你的告警阈值设在90%就没有预警作用，等告警出来系统实际已经卡死很久了。我自己的习惯参考是：

实践下来还有一个很重要的习惯是设置通知渠道通道。只配邮件不够，因为邮件延迟高、容易被忽略，最好加上短信或即时通讯机器人（比如钉钉/飞书/企微的Webhook）。作业里用短信可能有成本顾虑，那就用Webhook通知。

4.2 故障演练：验证你的"高可用"不是PPT

高可用不是配完就结束了，要验证。这是我特别想强调的一点。哪怕你答辩时把架构图画得再漂亮，没有实测结果支撑，老师一句"你怎么证明它是高可用的"就能把你问倒。

实际的验证步骤如下：

第一步，先确认当前负载均衡下两台后端机器都处于健康状态，访问负载均衡的公网地址，能看到页面正常返回。

第二步，模拟故障。推荐操作方式是直接强制关机一台后端服务器（相当于模拟宕机），而不是停掉服务，这样更彻底。然后观察负载均衡控制台，等待几秒到几十秒，它会把故障节点摘除。

第三步，再次访问负载均衡地址，确认页面依然正常返回。你可能会观察到请求全部落在剩下那台健康机器上。

第四步，开机恢复故障节点，等待健康检查确认它重新变为健康状态，再观察流量是否恢复了均衡分发。

我把测试结果记录下来，整理成一张表格，答辩时直接展示：

这份表直观证明你的架构确实扛住了单点故障。

另外，我还建议做一次安全组规则的验证：临时删掉负载均衡到后端8080端口的放行规则，观察后端会在下一个检查周期集体变不健康；再恢复规则，后端自动恢复正常。这种对"配置变更如何影响系统"的感知能力，比背一百道面试题更能证明你不是只会点鼠标。

4.3 成本控制：做一个有成本意识的人

云计算的作业里不要求优化成本，但如果你能在文档里写一段"成本分析"，会显得很专业。比如你的两台按量付费服务器，每天费用大概多少；对象存储存储量很小，费用基本可以忽略；负载均衡按流量计费，页面访问量低所以费用也极低。

更进一步，你可以提一下优化方案：非工作时间释放实例、使用抢占式实例、把低频访问数据转低频存储类型等。这些成本优化策略，恰恰是面试中高频出现的场景问题"一个业务上云了怎么省钱"的核心答案。

5. 作业答辩与面试场景：把动手过程变成经验资本

作业做完不是终点。你花了一两周时间踩坑、部署、验证，如果没有好好把它转化成答辩时的表达和面试简历里的项目经验，就太亏了。这节我说一下怎么把这次作业"讲"出价值。

5.1 架构图怎么画才不露怯

很多同学的架构图是直接从控制台截图拼出来的，箭头乱飞，老师根本看不懂。架构图的正确画法是分层：

用户 → 负载均衡（公网入口）→ 后端服务器A/后端服务器B（分别在不同可用区）→ 云数据库/对象存储

每一层之间标注协议和端口（HTTP 80/8080、MySQL 3306等）。如果你配了安全组和VPC，可以在图上画出子网边界，标注安全组规则。

更关键的是，画出"故障切换路径"：当A可用区故障，流量如何自动转到B可用区。这张图才是高可用的灵魂，也是答辩时最能展示理解深度的一张图。

5.2 高频面试题与项目话术

做完这次作业后，下面这些问题你应该能非常自然地回答上来。它们同时也是云计算运维面试题里出现频率最高的内容：

负载均衡有哪几种调度算法？你选了什么，为什么？

你可以回答：常见的算法有轮询、加权轮询、最少连接数、IP哈希等。我作业里选的是加权轮询，因为两台机器规格相同，轮询能均匀分发；如果未来节点规格不同或者连接处理成本不同，可以改成加权或最少连接数。

健康检查的原理是什么？不健康了会怎样？

你可以结合本次作业回答：负载均衡定期向后端服务器发起探测请求，例如每5秒探测一次/health接口，连续3次失败就标记不健康并停止转发流量，连续3次成功再恢复。这在云环境里相当于系统自带的"心跳监测"。

Session如果要保持，你怎么处理？

你可以回答两层：一是在负载均衡层开启会话保持，让同一来源IP固定到同一台后端；二是更推荐的方案，把Session从服务器本地抽出来放到共享存储里，比如云数据库或缓存服务。这样即使负载均衡把请求打到不同节点也不会丢登录态。

你的数据库是单机还是高可用？如果单机挂了怎么办？

这是最容易暴露项目深度的问题。如果你只是本地部署了MySQL，就老老实实说：作业里为了简化部署用了单机数据库，但生产上我会使用云数据库的高可用版本，主备切换时对应用无感知，同时开启自动备份和日志备份以便恢复。

成本优化你能想到哪些手段？

结合前面的成本章节回答：弹性伸缩控制实例数量，按量付费改成包年包月或抢占式实例，对象存储生命周期沉降低频/归档存储，负载均衡按流量计费避免固定带宽浪费。这些都是运维面试中高频性价比考题的核心答案。

安全组和网络ACL的区别是什么？

简洁版本：安全组是实例级别的防火墙，有状态（返回流量自动放行，你只需要关心入方向规则）；网络ACL是子网级别的防火墙，无状态（需要同时配置入方向和出方向规则）。二者可以叠加使用，实现纵深防御。

5.3 从作业到学习路线图的延伸建议

如果你现在还是个学生，或者刚转行做运维，不要指望一次作业就掌握所有内容。云计算运维学习路线图我粗线条梳理一个顺序：

基础设施层：Linux基础 → 网络基础（IP、端口、DNS、HTTP）→ 脚本语言（Bash/Python）
云平台层：VPC/子网/安全组 → 计算（云服务器、弹性伸缩）→ 存储（对象存储、块存储）→ 数据库（云数据库与缓存）
运维工具层：监控告警 → 日志分析 → 自动化部署（Ansible/Terraform）→ CI/CD
容器化（后续扩展）：Docker → Kubernetes → Helm

这次作业帮你打通的是"云平台层"这条线，也是整个路线图里最重要的一段。你甚至可以在这个基础上继续扩展：试着用Terraform把这次作业的全部资源管理起来，下次重建环境只需要一条命令；或者用Ansible让两台机器一键部署到一致状态。如果能做到这一步，你已经不是在做作业了，而是在做真正的运维工程项目。

6. 实操中绝对不能犯的低级错误清单

最后这部分，算是我在带人做云上项目时总结的一批"提分/保命"要点。单独列成清单，方便你提交作业前逐项对照。

• 密钥不要传到公开仓库。云服务器登录如果用密钥对，私钥文件一旦泄露等于服务器被人接管。有些人习惯把密钥直接放到GitHub上，这是我在项目评审里见到的最大隐患。
• 安全组入方向来源尽量缩小范围。不要为了省事把所有端口都放给0.0.0.0/0，尤其是数据库端口3306。数据库只给应用服务器的内网IP放行就够了。
• 使用弹性公网IP而不是服务器自带的公网IP。云服务器如果被释放，它的公网IP也会被回收；把公网IP单独做成弹性EIP，可以灵活绑定到新的服务器上。这一点在负载均衡上也适用，CLB实例本身有固定的公网IP，不要依赖后端服务器的公网访问。
• 释放资源顺序要正确。调测完成后，先删负载均衡，再删后端服务器，然后删除VPC中的资源，最后再删VPC本身。顺序不对会提示"VPC内还有资源，无法删除"。
• 文档里截图要配说明。作业和项目周报一样，截图如果不配文字说明，老师/面试官根本不知道你想表达什么。每张图下方加一句"图X：负载均衡健康检查配置"，观感会好非常多。
• 善用标签（Tag）。给每台服务器打上"Name=web-server-a"、"Env=test"这样的标签，控制台一眼看出用途。虽然不是作业的硬性要求，但能从细节上体现你的工程习惯。

我在实际排查过程中发现，几乎所有作业翻车的根因，都不是"云产品不会用"，而是"网络拓扑和安全规则没想清楚就动手"。云计算的报错信息往往非常模糊——超时、拒绝连接、无法访问，这些背后可能藏着完全不同的原因。经验不足时，用最笨但也最可靠的办法，从数据链路的最外层逐层向内排查：访问不了，先看负载均衡有没有IP、再看安全组放没放通、再用命令行在后端上模拟请求、最后看应用日志。

把这次作业当成一次真正的生产系统来对待，等你养成了"每一步操作都问一句为什么"的习惯，不管是做作业、准备云计算运维面试还是以后进公司维护真实业务，都会顺畅得多。