第二阶段：计算服务 EC2 与服务器登录（SSH）¶

学习目标：

理解 EC2 在 AWS 中的角色

能独立创建一台 EC2 实例

理解密钥对、安全组的作用

能通过 SSH 登录 Linux 服务器

在 EC2 上成功跑起第一个 Web 服务

1. EC2 是什么？¶

EC2（Elastic Compute Cloud）是 AWS 提供的云服务器服务。

可以把 EC2 理解为：

一台你在云上租用的服务器（Linux / Windows），按小时或按秒计费。

EC2 解决的问题是：

不用买服务器硬件
不用搭建机房
几分钟即可获得一台可用服务器

2. EC2 的核心组成¶

创建一台 EC2，至少会涉及以下几个核心概念：

实例（Instance）：正在运行的一台服务器
AMI：操作系统模板
实例类型：CPU / 内存配置
存储（EBS）：服务器硬盘
密钥对（Key Pair）：登录凭证
安全组（Security Group）：防火墙

3. AMI（操作系统镜像）¶

AMI 是 EC2 的系统模板，决定了：

使用什么操作系统
是否预装软件

常见 AMI：

Amazon Linux（官方推荐）
Ubuntu
Windows Server

新手建议： 优先选择 Amazon Linux 或 Ubuntu。

4. 实例类型（Instance Type）¶

实例类型决定了一台 EC2 服务器的性能规格，主要体现在以下几个方面：

CPU 性能
内存大小
网络性能
是否适合突发负载或持续高负载

你可以把实例类型理解为：

“这台服务器的配置档位”
就像电脑的 i5 / i7，8GB / 16GB 内存一样。

4.1 为什么实例类型的选择很重要？¶

选择合适的实例类型，可以在以下三点之间取得平衡：

性能：服务器是否能流畅运行应用
稳定性：是否会频繁出现 CPU 打满、响应变慢
成本：是否花了不必要的钱

如果实例类型选择不当，常见问题包括：

CPU 经常 100%，接口响应变慢
用户不多，但服务器费用很高
应用运行不稳定，偶发超时

因此，在真实项目中，实例类型的选择是一个性能与成本的平衡问题。

4.2 常见实例系列说明（新手重点）¶

4.2.1 t 系列（突发型，学习首选）¶

t 系列是 AWS 中最常见、也是新手最应该接触的实例类型。

特点：

平时性能一般
在短时间内可以“突发”使用较高 CPU
成本低

适合场景：

AWS 学习与实验
测试环境
小型网站、管理后台

常见型号：

t2.micro
t3.micro

📌 新手必须记住：
AWS 免费额度通常包含 t2.micro 或 t3.micro，非常适合学习使用。

4.2.2 m 系列（通用型，生产常用）¶

m 系列是 CPU 与内存较为均衡的实例类型。

特点：

性能稳定
通用性强

适合场景：

普通 Web 服务
后端 API 服务
中小型业务系统

如果你在生产环境中不知道该选哪种实例类型，
m 系列通常是一个安全、稳妥的选择。

4.2.3 c 系列（计算增强型）¶

c 系列以计算能力为核心。

特点：

CPU 性能强
适合持续高计算负载

适合场景：

大量计算任务
批量数据处理
编译、转码、算法计算

📌 对新手来说，学习阶段一般不需要使用 c 系列。

4.2.4 r 系列（内存增强型）¶

r 系列以大内存为特点。

特点：

内存容量大
成本相对较高

适合场景：

内存型数据库
缓存系统
对内存依赖较高的应用

📌 新手阶段不推荐使用，了解即可。

4.3 学习阶段如何选择实例类型？¶

对于 AWS 新手来说，只需要记住下面这条原则：

学习 / 实验 / 个人项目 → 选择 t2.micro 或 t3.micro

等你进入真实项目或生产环境后，再根据业务特点选择 m / c / r 系列。

4.4 实例类型选择对照表¶

使用场景	推荐实例类型
AWS 学习 / 实验	t2.micro / t3.micro
普通 Web 服务	m 系列
高计算任务	c 系列
内存密集应用	r 系列

5. 存储（EBS）¶

EBS（Elastic Block Store）是 EC2 使用的云硬盘服务。

你可以把 EBS 理解为：

EC2 的硬盘（系统盘或数据盘）

5.1 EBS 的基本作用¶

EBS 主要用于：

安装操作系统（系统盘）
存储应用程序和数据（数据盘）

一台 EC2 实例通常至少会挂载一块 EBS。

5.2 EBS 与 EC2 的关系（新手易混点）¶

需要明确区分：

EC2 是计算资源（服务器）
EBS 是存储资源（硬盘）

两者关系如下：

EC2（云服务器）
└── EBS（云硬盘）

关键特性：

EC2 重启或停止时，EBS 中的数据不会丢失
删除 EC2 时，可以选择是否同时删除 EBS

5.3 快照（Snapshot）是什么？¶

快照是 EBS 的备份机制，用于保存某一时间点的磁盘状态。

快照可以用于：

数据备份
数据恢复
快速复制环境

可以理解为：

硬盘的“时间点备份”

5.4 新手常见误区¶

以为删除 EC2 一定会删除所有数据
在没有快照的情况下直接删除服务器
把重要数据只存放在 EC2 上而没有备份

📌 正确的意识是：
重要数据必须有备份，要么快照，要么放在 S3 / 数据库中。

5.5 学习阶段如何使用 EBS？¶

在学习阶段，你只需要做到以下几点：

默认配置即可，不必纠结规格
系统盘使用一块 EBS
删除资源前确认是否保留 EBS
重要操作前可先创建快照

本小节总结¶

实例类型 决定服务器性能与成本
t 系列 是新手和学习阶段的首选
EBS 是 EC2 的硬盘，不是临时存储
快照是保护数据的重要手段

6. 密钥对（Key Pair）¶

在创建 EC2 实例并通过 SSH 登录时，密钥对是最重要的安全凭证之一。如果没有正确配置密钥对，你将无法登录服务器。

6.1 Key Pair 是什么？¶

Key Pair（密钥对）是一组非对称加密密钥，用于安全地登录 EC2 服务器。

它由两部分组成：

公钥（Public Key）
- 存储在 AWS
- 在创建 EC2 时自动写入服务器
私钥（Private Key，.pem 文件）
- 下载到你的本地电脑
- 用于证明“你是谁”

可以这样理解：

公钥 = 门锁
私钥 = 唯一能开这把锁的钥匙

只有同时拥有：

正确的用户名（如 ec2-user / ubuntu）
正确的私钥文件

才能成功登录服务器。

⚠️ 重要提醒：
私钥只会在创建时提供一次下载机会，丢失后无法再次获取。

6.2 Key Pair 的工作原理（新手版）¶

当你使用 SSH 登录 EC2 时，后台大致会发生以下过程：

你在本地使用私钥发起登录请求
服务器使用已保存的公钥进行校验
校验通过 → 允许登录
校验失败 → 拒绝连接

整个过程中：

私钥不会传输到服务器
密码不会在网络中传输

这也是 SSH 使用密钥登录比密码安全得多的原因。

6.3 为什么不用密码登录？¶

AWS 默认不推荐、也不鼓励使用密码登录服务器，主要原因包括：

密码容易被暴力破解
弱密码风险极高
需要额外配置，反而增加安全风险

而使用密钥登录具有以下优势：

私钥长度远大于密码，几乎无法被暴力破解
私钥只存在于本地，不会在网络中传输
符合云环境和生产系统的安全规范

📌 在真实项目中：
“只允许密钥登录，禁止密码登录”通常是基础安全要求。

6.4 如何创建 Key Pair（实战步骤）¶

方式一：在创建 EC2 时生成（最常见，推荐）¶

步骤：

登录 AWS 控制台 → EC2
点击 Launch Instance（启动实例）
在 Key pair（login） 设置中：
选择 Create new key pair
配置参数：
Key pair name：如 my-ec2-key
Key pair type：RSA（默认）
Private key file format：.pem
点击 Create key pair
浏览器会自动下载 .pem 文件

注意事项：

.pem 文件只会下载一次
请立即保存到安全位置

方式二：提前创建 Key Pair（可复用）¶

步骤：

AWS 控制台 → EC2 → Key Pairs
点击 Create key pair
填写名称，选择 .pem 格式
下载并妥善保存私钥
创建 EC2 时直接选择该 Key Pair

适用场景：

多台 EC2 使用同一套登录凭证
团队内部统一管理服务器密钥

6.5 私钥文件的安全存放建议（非常重要）¶

不要上传到 GitHub 或任何代码仓库
不要通过聊天工具随意发送
建议只保存在个人电脑或加密存储中
设置文件权限为只读（Linux / macOS）

chmod 400 my-ec2-key.pem

6.6 私钥丢失了怎么办？¶

这是新手最常见的问题之一，必须提前了解：

❌ AWS 无法帮你找回私钥
❌ 无法重新下载同一把私钥
✅ 解决思路：
- 重新创建 Key Pair
- 或通过系统方式重新配置 SSH（进阶内容）

📌 学习阶段建议：
如果私钥丢失，直接新建一台 EC2 即可。

6.7 本小节总结¶

Key Pair 是 EC2 SSH 登录的唯一凭证
公钥在 AWS，私钥在本地
私钥只提供一次下载机会
密钥登录比密码登录安全得多
私钥丢失几乎等同于“无法登录服务器”

7. 安全组（Security Group）¶

安全组（Security Group）是 EC2 使用的虚拟防火墙，用于控制：

谁可以访问你的服务器
可以访问哪些端口
可以使用什么协议

你可以把安全组理解为：

服务器门口的门卫（白名单制）

7.1 安全组的核心特点（新手必记）¶

默认拒绝所有入站流量
只允许明确放行的规则
有状态（Stateful）
出站请求的返回流量会自动允许

📌 重点记住：
安全组是白名单，不是黑名单。

7.2 常见端口及用途¶

22（SSH）：远程登录服务器（建议只对自己 IP 开放）
80（HTTP）：普通 Web 访问
443（HTTPS）：加密 Web 访问

学习阶段常用：

22 → SSH 登录
80 → Web 访问（Nginx）

7.3 新手常见安全组错误¶

忘记放行 22，无法 SSH
端口放行了但来源 IP 配错
22 对 0.0.0.0/0 全开放（有风险）
安全组未正确绑定到实例

8. 创建第一台 EC2（实战）¶

本节将前面学到的内容全部串起来，完成第一台真正可用的云服务器。

8.1 创建流程¶

选择 AMI（Amazon Linux / Ubuntu）
选择实例类型（t2.micro / t3.micro）
创建或选择 Key Pair
配置安全组（22 / 80）
启动实例

8.2 创建前检查清单¶

Key Pair 已下载并保存
安全组已放行 22 / 80
实例类型在免费额度内

9. SSH 登录 EC2¶

当实例状态为 Running 后，即可登录服务器。

9.1 Linux / macOS¶

chmod 400 mykey.pem
ssh -i mykey.pem ec2-user@EC2_PUBLIC_IP

9.2 Windows（PowerShell）¶

ssh -i mykey.pem ec2-user@EC2_PUBLIC_IP

9.3 常见登录失败原因¶

安全组未放行 22
使用了 Private IP
Key Pair 不匹配
用户名错误（Amazon Linux ≠ Ubuntu）

10. 成功登录后你在干什么？¶

当你看到提示符时：

[ec2-user@ip-xxx-xxx-xxx ~]$

说明：

已登录真实 Linux 云服务器
当前是普通用户
可以安装软件、部署服务

11. 部署第一个 Web 服务（Nginx）¶

11.1 安装并启动¶

sudo yum update -y
sudo yum install -y nginx
sudo systemctl start nginx

11.2 浏览器访问¶

在浏览器中输入：

http://EC2_PUBLIC_IP

看到 Nginx 欢迎页，说明部署成功 🎉

11.3 本阶段的意义¶

你已经完成：

云服务器创建
安全登录
Web 服务部署
对外访问验证

这是后续学习前后端分离、负载均衡、高可用的基础。

12. 常见问题排查¶

无法 SSH：检查安全组 22 端口
无法访问网页：检查安全组 80 端口
登录超时：确认使用的是 Public IP

13. 本阶段总结¶

EC2 是云服务器
Key Pair 是登录凭证
安全组是防火墙
SSH 是登录方式
成功跑起服务是信心建立点

14. Nginx 简介（新手必知版）¶

在前面的内容中，我们已经在 EC2 上成功安装并启动了 Nginx，并通过浏览器访问到了页面。本节将用最通俗、最贴近实际项目的方式，解释：Nginx 是什么？它在系统中负责什么？为什么几乎所有线上系统都会用到它？

14.1 Nginx 是什么？¶

Nginx 是一个高性能的 Web 服务器和反向代理服务器。

你可以把它理解为：

一款专门负责“接待浏览器请求”的软件。

当用户在浏览器中访问：

http://你的服务器IP

真正接收这个请求、并返回页面内容的，就是运行在 EC2 上的 Nginx。

14.2 如果不使用 Nginx 会怎样？¶

假设你只有一个后端程序（如 Spring Boot / Django）：

后端程序本身也能处理 HTTP 请求
但它并不擅长：
- 处理大量并发连接
- 高效返回静态资源（HTML / CSS / JS / 图片）
- 做请求转发、限流、缓存

因此，真实项目中几乎不会让后端程序直接面对浏览器。

典型结构是：

浏览器 → Nginx → 后端程序

👉 Nginx 负责“接待用户”，后端专心“处理业务逻辑”。

14.3 Nginx 在项目中的三种常见角色¶

14.3.1 作为 Web 服务器（最基础）¶

直接返回 HTML 页面
提供静态资源（CSS / JS / 图片）

你在本章中做的事情，正是让 Nginx 扮演这个角色。

14.3.2 作为反向代理（非常重要）¶

Nginx 可以将用户请求转发给后端服务：

用户 → Nginx → Spring Boot / Django

这样做的好处：

后端服务端口不暴露在公网
浏览器始终只访问 80 / 443 端口
后端程序可以自由重启、扩容

这是后面 前后端分离部署 和 负载均衡 的基础。

14.3.3 作为系统的统一入口（负载入口）¶

当系统中存在多台后端服务器时：

用户
  ↓
Nginx
  ↓
后端A / 后端B / 后端C

Nginx 可以将请求分发到不同服务器，提高系统的并发能力和稳定性。

👉 这正是后续学习 ALB / Auto Scaling 时的底层思想来源。

14.4 Nginx 与 EC2 的关系（新手容易混的点）¶

一定要区分清楚：

EC2 是服务器（机器）
Nginx 是运行在服务器上的软件

关系如下：

EC2（Linux 云服务器）
└── Nginx（Web 服务软件）

AWS 不会自动帮你安装 Nginx，你是在 EC2 上手动安装并运行了它。

14.5 为什么新手阶段一定要学 Nginx？¶

原因很简单：

几乎所有线上 Web 项目都会使用
是前端与后端之间的重要“缓冲层”
是学习负载均衡、高可用架构的基础

可以说：

学会 Nginx，意味着你已经迈出了“能部署系统”的关键一步。

14.6 本阶段你已经完成了什么？¶

到目前为止，你已经做到：

拥有一台真正的云服务器（EC2）
能通过 SSH 登录服务器
在云上运行了一个 Web 服务（Nginx）
能让浏览器访问你的服务器页面

这正是后续学习以下内容的基础：

后端服务部署
前后端分离架构
负载均衡与高可用设计

下一阶段，我们将学习 S3 + CloudFront，
把前端静态资源从服务器中解放出来，
进入真正的前后端分离架构。

15. 在 EC2 上部署 Spring Boot 项目（实战）¶

在前面的内容中，我们已经：

创建并登录了一台 EC2
成功运行了 Nginx
可以通过浏览器访问服务器

本节将完成一个非常重要的实战目标：

把一个真实的 Spring Boot 后端项目部署到 EC2，并通过浏览器访问接口。

这一步，意味着你已经真正具备了：
“把后端系统部署上线”的能力。

15.1 本节目标与整体架构¶

目标效果：

Spring Boot 项目运行在 EC2 上
监听指定端口（如 8080）
浏览器可以直接访问接口

整体结构如下：

浏览器
  ↓
EC2 公网 IP
  ↓
Spring Boot（8080）

（后续章节中，这里会升级为：浏览器 → Nginx → Spring Boot）

15.2 准备一个最简单的 Spring Boot 项目¶

示例 Controller：

@RestController
public class HelloController {

    @GetMapping("/hello")
    public String hello() {
        return "Hello from EC2!";
    }
}

确保本地可以访问：

http://localhost:8080/hello

15.3 在本地打包 Spring Boot 项目¶

mvn clean package

生成：

target/demo-0.0.1-SNAPSHOT.jar

15.4 将 Jar 包上传到 EC2¶

scp -i my-ec2-key.pem target/demo-0.0.1-SNAPSHOT.jar ec2-user@EC2_PUBLIC_IP:/home/ec2-user/

15.5 在 EC2 上安装 Java¶

sudo yum install -y java-17-amazon-corretto
java -version

15.6 启动 Spring Boot¶

java -jar demo-0.0.1-SNAPSHOT.jar

确认日志出现：

Tomcat started on port(s): 8080

15.7 放行 8080 端口（学习阶段）— 步骤详解¶

第 1 步：确认你的 EC2 使用的是哪个安全组¶

进入 AWS 控制台 → EC2
左侧选择 Instances（实例）
选中你创建的那台 EC2
下方详情页找到 Security（安全） 标签页
在 Security groups（安全组） 一栏可以看到当前绑定的安全组名称（一般是 sg-xxxxxxx）

📌 你后面修改规则，一定要改的就是这一组安全组。

第 2 步：进入安全组的入站规则配置¶

在实例详情的 Security groups 里点击安全组链接（sg-xxxxxx）
进入 Security Groups（安全组） 页面后
切换到 Inbound rules（入站规则）
点击右上角 Edit inbound rules（编辑入站规则）

第 3 步：新增一条 8080 的入站规则¶

在编辑页面中点击 Add rule（添加规则），然后填写：

Type（类型）：Custom TCP
Port range（端口范围）：8080
Source（来源）：学习阶段选择 0.0.0.0/0

（可选）如果页面有 IPv6 的来源，可以不填；或填 ::/0 表示允许 IPv6。

✅ 你最终应该看到一条规则类似：

Type	Protocol	Port range	Source
Custom TCP	TCP	8080	0.0.0.0/0

第 4 步：保存规则¶

点击右下角 Save rules（保存规则）

保存后规则会几乎立即生效（通常几秒内）。

第 5 步：验证是否放行成功¶

在浏览器中打开：

http://EC2_PUBLIC_IP:8080/hello

如果能看到返回内容（例如 Hello from EC2!），说明放行成功。

15.8 浏览器访问验证¶

http://EC2_PUBLIC_IP:8080/hello

返回成功即部署完成 🎉

15.9 本节意义¶

你已经完成：

后端项目打包
云服务器部署
公网访问接口

这是真正的“部署能力起点”。

16. Spring Boot + Nginx 反向代理（生产形态）¶

直接暴露 8080 并不符合生产规范，本节将升级为：

浏览器
  ↓ 80
Nginx
  ↓ 8080
Spring Boot

16.1 为什么要用 Nginx 反向代理？¶

隐藏后端端口
提供统一入口
支持扩展与负载

结论：
Nginx 对外，Spring Boot 对内。

16.2 安全组调整建议¶

端口	说明
22	SSH
80	Web
8080	关闭公网（生产）

16.3 确认 Spring Boot 运行¶

ss -lntp | grep 8080

16.4 配置 Nginx 反向代理¶

编辑配置：

sudo vi /etc/nginx/nginx.conf

示例：

server {
    listen 80; #监听 80 端口（HTTP 默认端口）
    server_name _; #_ 表示“匹配所有未明确指定域名的请求”

    location / { #定义 URL 路径匹配规则
        proxy_pass http://127.0.0.1:8080; #把用户请求 转发 给后端服务
        proxy_set_header Host $host; #把原始请求的 Host 信息转发给后端
        proxy_set_header X-Real-IP $remote_addr; #把客户端真实 IP 传给后端
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; #记录完整的请求链路 IP（标准做法）
    }
}

16.5 检查并重启 Nginx¶

sudo nginx -t
sudo systemctl restart nginx

16.6 浏览器访问验证¶

http://EC2_PUBLIC_IP/hello

无需端口号，说明反向代理成功 🎉

16.7 当前架构总结¶

用户
 ↓
Nginx（入口）
 ↓
Spring Boot（业务）

这是后续高可用与负载均衡的基础。

16.8 本节总结¶

不直接暴露 Spring Boot
Nginx 作为统一入口
生产级部署雏形完成