wangqifan/aws-doc

Fork 0

wangqifan a80067d684 all

2026-05-08 10:24:39 +08:00

6.1 KiB

Raw Blame History

第19天：核心服务综合实战——设计一个完整的应用架构

今天你将学到什么

今天是第二阶段的收尾。我们用一个完整的项目案例，把前面学到的所有核心服务串联起来，看看它们在真实架构中是怎么配合工作的。

项目背景：设计一个外卖点餐平台

假设你要做一个类似"美团外卖"的简化版平台：

用户可以浏览餐厅和菜品
用户可以下单、支付
商家可以接单、更新订单状态
用户可以实时查看订单进度
需要支持全国用户访问

架构全景图

用户手机/电脑
      ↓
Route 53（域名解析）
      ↓
CloudFront（静态资源加速：图片、前端页面）
      ↓
ALB（负载均衡，分发到多台服务器）
      ↓
Auto Scaling Group（应用服务器，自动伸缩）
      ↓
├── ElastiCache Redis（缓存热门餐厅、菜品信息）
├── Aurora MySQL（用户信息、订单数据、商家信息）
├── DynamoDB（实时订单状态、骑手位置）
├── S3（菜品图片、商家 Logo、用户头像）
└── SQS + Lambda（异步处理：发通知、更新统计）

每个服务的角色

Route 53 — 域名入口

用户输入 www.waimai.com
Route 53 把域名解析到 CloudFront 的地址
配置健康检查：如果主站挂了，自动切到备用站

CloudFront — 全球加速

缓存静态资源：菜品图片、前端 JS/CSS、商家 Logo
全国各地的用户都能快速加载页面
减轻源站压力（图片请求不用每次都打到服务器）

ALB — 流量分发

把用户请求均匀分配给多台应用服务器
路径路由：/api/orders/* → 订单服务，/api/restaurants/* → 餐厅服务
健康检查：某台服务器挂了自动剔除

Auto Scaling — 弹性伸缩

午餐高峰（11:00-13:00）：自动扩展到 20 台服务器
凌晨低谷（2:00-6:00）：自动缩减到 3 台服务器
策略：CPU 使用率保持在 60%

ElastiCache Redis — 缓存加速

缓存热门餐厅列表（避免每次都查数据库）
缓存用户会话（登录状态）
缓存菜品信息（菜品不会每秒都变）
效果：响应时间从 50ms 降到 5ms

Aurora MySQL — 核心业务数据

存储：用户信息、商家信息、菜品详情、订单记录、支付记录
Multi-AZ 部署：主库挂了自动切换到备库
2 个只读副本：分担查询压力
为什么选 Aurora：需要复杂查询（统计报表、搜索筛选）

DynamoDB — 实时数据

存储：订单实时状态（待接单→制作中→配送中→已送达）
存储：骑手实时位置（每 5 秒更新一次）
为什么选 DynamoDB：更新频率极高、查询简单（按订单 ID 查）、需要毫秒级响应

S3 — 文件存储

菜品图片（商家上传）
用户头像
商家营业执照扫描件
配合 CloudFront 分发到全国

SQS + Lambda — 异步处理

用户下单后 → 消息进入 SQS → Lambda 发送短信通知商家
订单完成后 → 消息进入 SQS → Lambda 更新用户积分
每日凌晨 → 定时触发 Lambda → 生成商家结算报表

网络设计

VPC (10.0.0.0/16)
├── 公有子网 (面向互联网)
│   ├── ALB
│   └── NAT Gateway
├── 应用子网 (私有)
│   └── EC2 应用服务器 (Auto Scaling)
└── 数据子网 (私有，最安全)
    ├── Aurora MySQL
    ├── ElastiCache Redis
    └── (DynamoDB 和 S3 通过 VPC Endpoint 访问，不走公网)

安全组规则：

ALB：只允许 80/443 端口的外部流量
应用服务器：只允许来自 ALB 的流量
数据库：只允许来自应用服务器的流量
层层隔离，外部用户永远接触不到数据库

一个请求的完整旅程

用户打开 APP，浏览附近的餐厅：

APP 请求 api.waimai.com/restaurants?lat=39.9&lng=116.4
Route 53 解析域名 → CloudFront 地址
CloudFront 发现这是 API 请求（不缓存）→ 转发到 ALB
ALB 选择一台健康的应用服务器
应用服务器先查 Redis 缓存：有附近餐厅的数据吗？
- 有（缓存命中）→ 直接返回，耗时 5ms
- 没有（缓存未命中）→ 查 Aurora 数据库 → 结果写入 Redis → 返回
响应经过 ALB → CloudFront → 到达用户 APP

整个过程：50-200ms。用户感觉"秒开"。

成本估算（月）

服务	配置	月费估算
EC2 (Auto Scaling)	3-20 台 t3.large	¥2,000-5,000
Aurora	db.r6g.large + 2 只读副本	¥4,000
ElastiCache	2 节点 cache.r6g.large	¥3,000
DynamoDB	按需模式	¥500-2,000
S3	500GB 图片	¥100
CloudFront	2TB 流量	¥1,500
其他	ALB、NAT、Route53	¥1,000
总计		¥12,000-17,000/月

对于一个日活几万用户的平台来说，这个成本是合理的。

关键设计决策总结

决策	选择	原因
主数据库	Aurora MySQL	需要复杂查询、事务、报表
实时数据	DynamoDB	高频更新、简单查询、毫秒响应
缓存	Redis	减少数据库压力、加速响应
文件存储	S3 + CloudFront	图片多、需要全国加速
异步处理	SQS + Lambda	解耦、削峰、按需付费
伸缩策略	Auto Scaling	应对午餐/晚餐高峰

今天的小测验

为什么这个架构同时用了 Aurora 和 DynamoDB 两种数据库？
如果不用 CloudFront，用户体验会有什么变化？
为什么"发通知"这个操作要用 SQS 异步处理，而不是下单时同步发送？
如果午餐高峰期流量突然暴涨 5 倍，这个架构的哪些部分会自动应对？

明天预告

进入第三阶段：安全与身份。明天深入学习 IAM 策略的编写——用精确的规则控制"谁能对什么资源做什么操作"。

6.1 KiB Raw Blame History Unescape Escape