云计算并不是“把服务器放到网上”这么简单，而是把计算、网络、存储、安全和流量管理等基础设施能力抽象成可以按需创建和管理的资源。
本文主要从运维视角理解公有云中的 ECS、VPC、Subnet、Route Table、安全组、SLB、NAT Gateway、块存储、对象存储、文件存储，并最终将这些组件组合成一个可以实际运行的 Web 应用架构。
一、什么是云计算
1.1 云计算
传统服务器部署通常需要：
购买物理服务器 ↓机房 ↓网络 ↓电源 ↓操作系统 ↓应用而云计算将这些基础设施能力抽象为：
ComputeNetworkStorageSecurityLoad Balancing用户通过控制台、API 或 CLI 创建资源：
User │ ▼Cloud API / Console │ ├── Compute ├── Network ├── Storage └── Security因此，云计算本质上是一种：
按需获取计算资源+通过网络管理资源+按使用规模进行弹性配置的基础设施模式。
1.2 公有云
公有云是由云服务提供商建设并运营的云平台。
例如：
Alibaba CloudAWSMicrosoft AzureGoogle Cloud用户不需要自己建设：
机房物理服务器交换机存储设备而是直接使用云厂商提供的资源。
例如在阿里云中：
ECSVPCSLBNAT GatewayOSS共同组成云上的基础设施。
其中：
ECS→ 计算
VPC→ 网络
SLB→ 流量分发
NAT Gateway→ 出口访问
OSS→ 对象存储1.3 IaaS、PaaS、SaaS
云计算服务通常可以按抽象程度分为：
IaaSPaaSSaaSIaaS
IaaS（Infrastructure as a Service）提供比较底层的基础设施能力。
例如：
虚拟机网络磁盘负载均衡用户仍然需要负责：
操作系统软件应用数据典型：
ECSEC2Azure Virtual MachinesPaaS
PaaS 在基础设施之上进一步托管：
运行环境中间件数据库容器平台用户更加关注：
应用而不是：
虚拟机操作系统SaaS
SaaS 则直接提供：
可使用的软件例如：
在线办公系统邮件服务在线 CRM可以简单理解：
IaaS→ 我租基础设施
PaaS→ 我主要部署应用
SaaS→ 我直接使用软件二、云服务器
2.1 ECS 是什么
不同云厂商名称不同。
阿里云通常使用：
ECSElastic Compute ServiceAWS 对应常见的是：
EC2Elastic Compute CloudAzure 则使用：
Virtual Machines它们解决的问题基本相同：
提供云上的虚拟计算机因此可以抽象成：
Cloud Server │ ├── CPU ├── Memory ├── OS ├── Disk └── Network例如创建一个 ECS 后：
ECS │ ├── Ubuntu ├── 2 vCPU ├── 4 GB Memory ├── System Disk └── Private IP然后就可以像管理普通 Linux 服务器一样：
ssh root@<public-ip>进行：
软件安装服务部署配置管理日志排查监控2.2 实例规格
云服务器通常可以选择：
CPUMemoryNetworkStorage例如：
2 vCPU4 GiB Memory100 GB Disk不同实例规格还可能对应：
CPU 型Memory 型计算型通用型网络增强型因此购买云服务器时，不应该只看：
CPU 核数还需要关注：
内存网络带宽磁盘类型IOPS实例网络能力价格2.3 镜像
创建 ECS 时通常需要选择：
Image也就是服务器初始操作系统和软件环境的模板。
例如：
UbuntuDebianRocky LinuxAlibaba Cloud LinuxWindows Server整体过程：
Image │ ▼Create ECS │ ▼Running Instance镜像还可以来自：
官方镜像自定义镜像市场镜像共享镜像常见运维场景：
服务器 A │ ▼制作自定义镜像 │ ▼服务器 B / C / D这样可以快速复制基础环境。
三、云服务器磁盘
3.1 系统盘与数据盘
云服务器一般至少涉及：
System DiskData Disk例如：
ECS │ ├── System Disk │ └── / │ └── Data Disk └── /data系统盘主要存放：
操作系统系统软件数据盘更适合：
数据库业务文件日志应用数据3.2 块存储
云平台的云盘通常属于：
Block Storage可以把它理解成：
云上的虚拟硬盘操作系统看到的仍然类似：
/dev/vda/dev/vdb然后可以：
lsblk查看。
例如：
vda├── vda1└── vda2
vdb可以进一步：
mkfs.ext4 /dev/vdbmkdir /datamount /dev/vdb /data因此：
Cloud Block Storage ↓Virtual Disk ↓Linux Filesystem3.3 云盘类型
云平台通常会提供不同性能级别的云盘，例如：
普通型高性能型SSDESSD / Premium SSD性能通常需要关注：
IOPSThroughputLatency因此数据库服务器选磁盘时，不能只看：
500 GB还需要关注：
IOPS吞吐量延迟四、VPC 与云网络
4.1 什么是 VPC
VPC（Virtual Private Cloud）可以理解为：
云平台中属于你的逻辑隔离网络。
例如：
VPC10.0.0.0/16里面可以继续划分：
Subnet A10.0.1.0/24
Subnet B10.0.2.0/24ECS：
ECS A10.0.1.10
ECS B10.0.2.10都位于：
10.0.0.0/16范围内。
阿里云官方将 VPC 定义为逻辑隔离的私有网络，ECS、SLB、RDS 等资源都可以部署其中。
4.2 为什么需要 VPC
没有网络隔离时：
所有服务器 │ ▼同一个平面安全性和管理都会比较混乱。
而 VPC 可以形成：
VPC │ ┌────────┴────────┐ ▼ ▼ Public Subnet Private Subnet │ │ SLB │ Bastion │ ├── App ├── DB └── Redis这样可以把：
对公网服务和：
内部服务分离开。
五、Subnet
5.1 子网
Subnet 是 VPC 内部进一步划分的网络。
例如：
VPC10.0.0.0/16
├── Subnet A│ 10.0.1.0/24│├── Subnet B│ 10.0.2.0/24│└── Subnet C 10.0.3.0/24不同云厂商可能使用：
SubnetvSwitchSubnet等不同术语。
在阿里云中常见：
VPC ↓vSwitchvSwitch 是 VPC 中进一步划分的网络资源。
5.2 公网子网与私网子网
从架构设计角度经常会使用：
Public SubnetPrivate Subnet例如：
Internet │ ▼ Public Subnet │ SLB │ ┌─────────┴─────────┐ ▼ ▼ Private Subnet Private Subnet │ │ App 1 App 2 │ │ └─────────┬─────────┘ ▼ Database这里：
SLB→ 对外提供入口
App→ 私网运行
DB→ 更加严格限制访问六、Route Table
6.1 路由表是什么
云 VPC 中的 Route Table 决定：
数据包应该往哪里走例如：
10.0.0.0/16→ local
0.0.0.0/0→ Internet / NAT Gateway可以理解成：
Destination │ ▼Route Table │ ▼Next Hop阿里云官方将路由表描述为指导 VPC 流量转发的网络路径配置，并通过路由条目决定流量的下一跳。 (alibabacloud.com)
6.2 默认路由
例如：
0.0.0.0/0代表：
所有 IPv4 目的地址如果配置：
0.0.0.0/0→ NAT Gateway就可以让私网资源通过 NAT 出网。
6.3 路由与安全组不是一回事
一个非常重要的区别：
Route Table→ “流量往哪里走？”
Security Group→ “允许不允许？”例如：
Route Table→ 找得到 Database
Security Group→ 不允许 5432最终仍然：
连接失败因此云网络排障一定要把：
RoutingSecurity分开看。
七、云安全组与 ACL
7.1 Security Group
安全组是一种与云资源关联的网络访问控制机制。
可以理解成：
ECS │ └── Security Group ├── Inbound Rules └── Outbound Rules例如：
允许：22/tcp80/tcp443/tcp拒绝：
330654326379对公网开放的安全组应该尽量遵循：
最小开放范围例如 SSH：
0.0.0.0/0意味着：
任何公网地址都可能尝试访问如果条件允许，更合理：
你的办公公网 IP→ TCP 227.2 Network ACL
不同云厂商的网络 ACL 能力和实现方式存在差异，但通常可以理解为：
Subnet / Network level的访问控制。
因此可以粗略区分：
Security Group→ 资源 / 网卡层面的访问控制
Network ACL→ 网络 / 子网层面的访问控制实际规则模型需要根据具体云平台确认。
7.3 Security Group 与 Linux Firewall
云上通常存在多层安全控制：
Internet │ ▼Cloud Security Group │ ▼ECS Network │ ▼Linux Firewall │ ▼Application因此：
安全组放行≠Linux 防火墙一定放行反过来也一样：
Linux Firewall 放行≠安全组一定放行这也是云上 Linux 排障最常见的问题之一。
八、云负载均衡 SLB / ELB
8.1 为什么需要负载均衡
假设只有一台 Web Server：
Client │ ▼Web Server当服务器：
宕机流量过大升级维护整个业务可能受到影响。
增加多个服务器：
Load Balancer │ ┌─────────┼─────────┐ ▼ ▼ ▼ Web 1 Web 2 Web 3Load Balancer 负责将流量分发到后端。
阿里云目前使用 SLB（Server Load Balancer）作为其负载均衡服务总称，并包含 ALB、NLB、CLB 等不同类型。 (alibabacloud.com)
AWS 常见对应产品：
ELB ├── ALB └── NLB8.2 四层与七层
负载均衡大致可以：
L4L7来理解。
L4
根据：
IPPortTCPUDP进行流量转发。
例如：
TCP :80TCP :443L7
可以进一步理解：
HTTPHTTPSHostPathHeader例如：
example.com/api ↓API Service
example.com/ ↓Web Service因此：
L4→ TCP / UDP
L7→ HTTP / HTTPS8.3 后端服务器
例如：
SLB │ ├── ECS 1 ├── ECS 2 └── ECS 3SLB 需要知道：
哪些实例可以接收流量因此通常配置：
Backend ServerBackend PoolListener8.4 健康检查
如果：
ECS 1已经：
宕机但负载均衡仍然把请求发送给它，就会出现：
请求失败因此需要：
Health Check例如：
GET /health如果：
HTTP 200认为：
Healthy否则：
Unhealthy流量就不再发送给异常实例。
8.5 负载均衡并不等于高可用
例如：
SLB │ └── 1 ECS如果 ECS 挂了：
SLB ↓没有健康后端仍然无法提供服务。
因此完整高可用通常需要：
Load Balancer+Multiple Backend Instances+Health Check进一步还需要考虑：
Multi-AZ等架构。
九、云 NAT Gateway 与公网访问
9.1 为什么需要 NAT
很多应用服务器不应该拥有公网 IP：
Internet XApp Server但它们可能需要访问：
软件仓库API镜像仓库NTP第三方服务这时候可以：
Private ECS │ ▼NAT Gateway │ ▼Internet也就是说：
私网服务器→ 通过 NAT 出网云厂商官方文档也将 NAT Gateway 用于让私网资源进行 Internet-bound outbound connectivity，并与入站负载均衡形成不同的流量方向。 (aws.amazon.com)
9.2 SNAT
SNAT（Source Network Address Translation）修改：
源 IP例如：
10.0.1.10访问公网：
8.8.8.8经过 NAT：
10.0.1.10 ↓203.0.113.10公网看到：
203.0.113.10于是：
Private IP ↓NAT ↓Public IP9.3 NAT Gateway 主要解决出站
典型架构：
Internet │ ▲ │ NAT Gateway ▲ │ Private Subnet │ ┌──────┴──────┐ ▼ ▼ App 1 App 2这里：
App → Internet可以通过 NAT。
但：
Internet → App并不会因为 App 使用 NAT 就自然成立。
因此：
NAT Gateway 的出站能力不能简单等同于公网入站能力。
9.4 公网 IP
云服务器常见两种 IP：
Private IPPublic IP私网：
10.x.x.x172.16.x.x192.168.x.x公网：
Internet-routable Address生产环境中更推荐：
应用服务器→ Private IP
公网入口→ SLB / CDN / Gateway而不是：
每台 ECS→ 一个公网 IP十、云存储
云存储主要可以分为：
Block StorageObject StorageFile Storage三种类型解决的问题并不相同。
Cloud Storage │ ┌───────────┼───────────┐ ▼ ▼ ▼ Block Object File │ │ │ Cloud OSS/S3 NAS/EFS Disk十一、块存储
11.1 Block Storage
块存储最接近传统硬盘。
例如：
ECS │ └── Block Disk │ ▼ /dev/vdbLinux 需要进一步：
mkfsmount才能使用文件系统。
例如：
sudo mkfs.ext4 /dev/vdbsudo mkdir /datasudo mount /dev/vdb /data适合：
操作系统数据库应用数据高 I/O 工作负载常见云厂商：
Alibaba Cloud → ESSD / Cloud DiskAWS → EBSAzure → Managed Disks11.2 块存储的特点
可以把它理解成：
“云上的硬盘”因此：
文件系统权限目录挂载等仍然主要由操作系统负责。
十二、对象存储
12.1 Object Storage
对象存储和块存储完全不同。
例如：
Bucket │ ├── image/a.jpg ├── image/b.png ├── video/demo.mp4 └── backup/db.sql这里：
Bucket→ 存储空间
Object→ 一个对象阿里云：
OSSObject Storage ServiceAWS：
S3Simple Storage ServiceAzure：
Blob Storage12.2 对象存储访问方式
对象存储通常通过：
HTTP / HTTPS API访问。
例如：
Application │ │ HTTPS ▼Object Storage而不是：
mount /dev/xxx所以：
Block Storage→ 类似磁盘
Object Storage→ 类似通过 API 操作对象12.3 对象存储的典型场景
非常适合：
图片视频备份日志归档安装包静态资源数据集模型文件例如 Web 应用：
User │ ▼Application │ ├── Metadata → Database │ └── Image → OSS这样就不需要把大量图片直接塞进数据库。
12.4 Bucket
对象存储通常以：
Bucket作为逻辑存储空间。
例如：
my-app-prod里面：
images/videos/backups/可以通过权限控制决定：
谁可以读谁可以写谁可以删除十三、文件存储
13.1 File Storage
文件存储提供共享文件系统。
例如：
Server A ─┐Server B ─┼── File StorageServer C ─┘多个服务器可以访问：
/shared这和：
Block Storage的最大区别之一是：
多个主机共享访问云平台中常见：
Alibaba Cloud NASAWS EFSAzure Files13.2 文件存储适合什么
例如：
共享目录上传文件多实例共享文件媒体文件用户 Home典型 Web 集群：
Load Balancer │ ┌────────┼────────┐ ▼ ▼ ▼ App1 App2 App3 │ │ │ └────────┼────────┘ ▼ Shared File这样三个实例都可以访问：
/shared/uploads十四、三类云存储对比
| 类型 | 访问方式 | 典型场景 | 代表产品 |
|---|---|---|---|
| Block | 块设备 / 文件系统 | OS、数据库、应用磁盘 | ESSD、EBS |
| Object | API / HTTP | 图片、视频、备份、归档 | OSS、S3 |
| File | 共享文件系统 | 多实例共享文件 | NAS、EFS |
一句话：
Block→ 像一块硬盘
Object→ 像一个通过 API 访问的文件仓库
File→ 像一个可以被多台机器挂载的共享目录十五、云存储中的备份
云上的存储并不意味着：
天然不会丢数据例如：
ECS被误删除：
实例删除如果数据只存在：
实例本地临时存储仍然可能丢失。
因此需要：
BackupSnapshotObject StorageReplication等机制。
例如：
Database │ ▼Backup │ ▼OSS / S3这样即使：
ECS 故障还可以：
Restore恢复数据。
十六、云服务器快照
云平台通常提供：
Snapshot例如：
Disk │ ▼Snapshot │ ▼New Disk可以用于：
升级前备份故障恢复环境复制镜像制作但要注意：
Snapshot主要是：
基础设施层面的磁盘状态保护而：
Database Backup则更关注数据库一致性和逻辑恢复。
因此：
云盘快照不能简单等同于数据库备份。
十七、云安全架构
一个比较常见的 Web 架构：
Internet │ ▼ CDN │ ▼ SLB │ ┌─────────┴─────────┐ ▼ ▼ Private Subnet Private Subnet │ │ App 1 App 2 │ │ └─────────┬─────────┘ ▼ Database同时：
App │ └── NAT Gateway │ ▼ Internet需要注意：
CDN→ 靠近用户缓存和加速内容
SLB→ 分发请求
NAT→ 私网资源出站
Security Group→ 控制访问
VPC→ 网络隔离这些组件职责不同。
十八、云服务器部署完整 Web 应用
现在把前面的组件组合起来。
18.1 基础架构
例如：
Internet │ ▼ DNS │ ▼ SLB │ ┌────────────┴────────────┐ ▼ ▼ App ECS 1 App ECS 2 Private IP Private IP │ │ └────────────┬────────────┘ ▼ Redis │ ▼ Database出口：
App ECS │ ▼NAT Gateway │ ▼Internet静态资源：
App │ └──► OSS十九、DNS
用户首先通过：
example.com访问网站。
DNS：
example.com │ ▼DNS Record │ ▼SLB Public IP / CNAME于是：
Browser │ │ DNS ▼SLB Address │ ▼Web Application常见 DNS 记录：
AAAAACNAMEMXTXT这里最重要的是理解：
DNS→ 名称解析
SLB→ 流量接入两者不是同一个组件。
二十、Nginx
如果 App 不直接对公网提供 HTTP，可以：
SLB │ ▼Nginx │ ▼ApplicationNginx 可以负责：
反向代理TLS静态资源请求转发例如：
example.com/api │ ▼ Nginx │ ▼ localhost:8080二十一、数据库安全
数据库通常不应该：
Internet │ ▼Database:5432更合理：
Internet │ ▼SLB │ ▼App │ ▼Private Database安全组：
DB↑只允许 App Security Group例如：
App → TCP 5432 → DB但：
Internet → TCP 5432 → DB不允许。
这就是：
分层网络+最小权限二十二、一个完整云 Web 请求流程
用户访问：
https://example.com整个过程可以理解为：
① DNS │ ▼example.com │ ▼② CDN / SLB │ ▼③ Nginx │ ▼④ Application │ ├──► Redis │ ├──► Database │ └──► OSS如果应用需要访问公网：
Application │ ▼NAT Gateway │ ▼Internet因此完整的云应用并不是：
一台 ECS而是：
DNS ↓CDN / SLB ↓ECS ↓Database / Redis / OSS ↓NAT等多个基础设施组件共同组成。
二十三、云上 Linux 故障排查
云上故障排查最大的特点：
Linux 本身+云平台基础设施两个层次同时存在。
例如用户访问失败：
Internet │ ▼DNS │ ▼SLB │ ▼Security Group │ ▼ECS │ ▼Linux Firewall │ ▼Nginx │ ▼Application │ ▼Database任何一层异常都可能：
访问失败二十四、实例问题
首先检查：
ECS 是否 Running然后：
CPUMemoryDiskNetworkSystem StatusLinux 内部再：
uptimetopfree -hdf -hss -lntpsystemctl status nginx如果：
ECS = Running不代表：
Nginx = Running更不代表：
网站 = 正常二十五、安全组问题
例如：
浏览器 ↓ECS:8080连接失败。
先检查：
Security Group是否允许：
TCP 8080然后检查：
ss -lntp | grep 8080如果：
安全组允许但是：
Linux 服务没有监听仍然无法访问。
因此：
Cloud Firewall+Linux Firewall+Application Port需要一起检查。
二十六、云网络故障
检查 VPC：
VPC ↓Subnet / vSwitch ↓Route Table ↓Security Group ↓ECS例如私网服务器无法访问 Internet：
ECS ↓Route Table ↓NAT Gateway ↓EIP ↓Internet逐层检查：
有没有默认路由？NAT Gateway 是否存在？NAT 规则是否正确？EIP 是否正常？安全策略是否允许？阿里云当前文档也强调，VPC 默认与 Internet 隔离，需要通过 EIP、NAT Gateway、SLB 等机制提供具体的公网访问能力。 (alibabacloud.com)
二十七、磁盘故障
云服务器常见：
磁盘空间不足磁盘 I/O 异常文件系统损坏数据盘未挂载先：
df -h再：
df -i查看磁盘：
lsblk查看挂载：
mount进一步：
iostat -xz 1如果发现：
/dev/vdb存在但没有挂载：
lsblk可以进一步判断：
分区文件系统挂载点/etc/fstab二十八、服务故障
例如：
ECS→ 正常
端口→ 开放
Nginx→ 无法启动继续：
systemctl status nginxjournalctl -u nginx检查配置：
nginx -t因此云上 Linux 故障排查应该始终：
云平台层+Linux 层+应用层一起考虑。
二十九、SLB 故障排查
如果：
用户 ↓SLB ↓ECS访问失败，可以依次检查：
DNS ↓SLB Listener ↓Backend Server ↓Health Check ↓Security Group ↓ECS Port ↓Application例如：
Health Check = Unhealthy这时应该检查：
端口路径协议应用监听地址安全组Nginx而不是优先怀疑：
SLB 本身坏了三十、NAT 故障排查
私网服务器：
curl https://example.com失败。
检查：
Route Table ↓NAT Gateway ↓SNAT ↓EIP ↓Security Policy然后在 Linux：
ip route确认默认路由。
进一步：
curl -v https://example.com查看：
DNSTCPTLSHTTP分别在哪一层失败。
三十一、云存储故障排查
31.1 Block Storage
检查：
lsblkdf -hmount确认：
磁盘存在分区存在文件系统存在挂载正常空间足够31.2 Object Storage
检查：
EndpointBucketCredentialsNetworkPermission常见问题：
AccessDeniedNoSuchBucketTimeoutDNS failure所以对象存储的问题通常不只是：
“磁盘有没有挂载”而是：
API+网络+权限31.3 File Storage
检查：
Mount TargetNetworkSecurity GroupDNSMount OptionsLinux：
mountdf -h如果共享目录不可访问：
网络+认证+挂载+后端文件存储需要一起检查。
三十二、云上监控
到了云环境之后，监控通常分成：
Cloud Metrics+Linux Metrics+Application Metrics例如：
Cloud├── ECS CPU├── Network├── Disk└── Load Balancer
Linux├── Process├── Memory├── Filesystem└── Socket
Application├── QPS├── Latency└── Error Rate因此：
云厂商监控并不能完全代替：
PrometheusGrafana实际生产环境很可能两者同时使用。
三十三、云计算与 Docker / Kubernetes
之前学习了：
DockerKubernetes现在放到云上：
Cloud │ VPC Network │ ┌───────────┼───────────┐ ▼ ▼ ▼ ECS SLB Storage │ ▼ Docker │ ▼ Kubernetes │ ▼ Pods云平台提供：
ComputeNetworkStorageLoad Balancer而：
Docker→ 容器
Kubernetes→ 容器编排因此：
云计算提供基础设施，容器提供应用打包方式，Kubernetes 负责在这些基础设施上运行和管理容器化工作负载。
三十四、云计算与 Ansible / CI/CD
前面还学习了：
AnsibleJenkinsDockerKubernetes现在可以组成：
Git │ ▼Jenkins │ ├── Build ├── Test └── Docker Image │ ▼ Registry │ ▼ Ansible │ ▼ Cloud ECS或者：
Git │ ▼Jenkins │ ▼Docker Image │ ▼Registry │ ▼Kubernetes │ ▼Cloud这就已经非常接近真实的：
云上 DevOps体系。
三十五、一个典型公有云 Web 架构
综合前面的知识，可以建立一个比较完整的架构：
Internet │ ▼ DNS │ ▼ CDN │ ▼ SLB │ ┌─────────────┼─────────────┐ ▼ ▼ ▼ ECS App1 ECS App2 ECS App3 Private IP Private IP Private IP │ │ │ └─────────────┼─────────────┘ │ ┌────────────┼────────────┐ ▼ ▼ ▼ Redis Database OSS │ Backup │ ▼ Object Storage
ECS App │ ▼NAT Gateway │ ▼Internet安全控制：
Internet │ ▼SLB │ ▼Security Group │ ▼ECS │ ▼Database数据库不直接：
0.0.0.0/0暴露到互联网。
三十六、云基础设施的核心关系
到这里可以把各个组件串成：
Cloud Platform │ ┌───────────────┼────────────────┐ ▼ ▼ ▼ Compute Network Storage │ │ │ ECS VPC │ │ ┌────┼────┐ │ │ ▼ ▼ ▼ │ │ Subnet Route SG │ │ │ │ │ NAT Block │ │ Object │ SLB File │ │ │ └───────────────┼────────────────┘ ▼ Application可以把它理解成：
ECS→ 计算在哪里运行
VPC→ 网络在哪里运行
Subnet→ 网络怎么划分
Route Table→ 流量往哪里走
Security Group→ 谁可以访问
SLB→ 请求发给谁
NAT→ 私网如何访问公网
Storage→ 数据存在哪里三十七、云上故障排查总模型
云上遇到：
“网站打不开”可以建立固定思维：
User Request │ ▼ DNS │ ▼ CDN / SLB │ ▼ Load Balancer │ ▼ Security Group │ ▼ ECS │ ┌──────┴──────┐ ▼ ▼ Linux Network │ │ ▼ ▼ Nginx/App Route/NAT │ ▼ Redis / DB │ ▼ Storage每一层都有自己的检查方法。
Linux：
topfree -hdf -hss -lntpsystemctl statusjournalctl网络：
ip addrip routesscurlpingtraceroute云平台：
InstanceSecurity GroupRoute TableLoad BalancerNAT GatewayStorage三十八、云计算中的高可用
“上云”本身并不等于：
高可用例如：
SLB │ └── ECS依然存在：
单点更合理：
SLB / | \ / | \ ECS1 ECS2 ECS3 │ │ │ └───────┼───────┘ │ Database进一步：
Availability Zone A │ ├── ECS └── Storage
Availability Zone B │ ├── ECS └── Storage这样即使某个：
实例甚至：
可用区发生故障，系统仍可能保持服务。
高可用最终依赖：
冗余+故障检测+流量切换+数据恢复而不是简单地：
“买一台更贵的 ECS”三十九、云计算的成本意识
云上资源是：
弹性+按使用付费因此运维不仅需要考虑：
可用性性能安全还需要考虑：
成本例如：
ECS磁盘公网带宽NAT GatewaySLBOSS日志快照都有可能产生费用。
因此生产架构需要考虑：
资源是否过大？是否存在闲置？日志保留是否过长？备份是否合理？公网流量是否过高？最终目标不是：
最贵而是：
满足 SLA+合理成本四十、总结
云计算最核心的基础组件，可以整理成：
ECS→ 计算
VPC→ 私有网络
Subnet→ 网络划分
Route Table→ 流量路径
Security Group→ 网络访问控制
SLB→ 负载均衡
NAT Gateway→ 私网出站
Block Storage→ 云硬盘
Object Storage→ 对象文件
File Storage→ 共享文件系统它们最终组合成：
Internet │ ▼ DNS │ ▼ SLB │ ┌─────────┴─────────┐ ▼ ▼ ECS ECS │ │ └─────────┬─────────┘ ▼ Private Network │ │ ▼ ▼ Redis DB │ ▼ OSS
ECS │ ▼ NAT Gateway │ ▼ Internet从运维角度，可以把整个云基础设施理解为：
计算 ↓网络 ↓安全 ↓存储 ↓流量 ↓监控 ↓故障恢复而排查问题时：
DNS ↓Load Balancer ↓Security Group ↓VPC / Route ↓ECS ↓Linux ↓Application ↓Database / Storage必须逐层定位。
云计算真正改变的并不是 Linux 服务器本身，而是把计算、网络、存储、安全和流量管理等基础设施能力变成了可以通过 API 快速创建、修改和销毁的资源。对于运维人员而言，核心能力也从“会登录一台服务器”进一步扩展成“理解整个云上基础设施是如何协同工作的”。