183 lines
6.1 KiB
Markdown
183 lines
6.1 KiB
Markdown
|
# 第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，浏览附近的餐厅：
|
|||
|
|
|
|||
|
|
1. APP 请求 `api.waimai.com/restaurants?lat=39.9&lng=116.4`
|
|||
|
|
2. Route 53 解析域名 → CloudFront 地址
|
|||
|
|
3. CloudFront 发现这是 API 请求（不缓存）→ 转发到 ALB
|
|||
|
|
4. ALB 选择一台健康的应用服务器
|
|||
|
|
5. 应用服务器先查 Redis 缓存：有附近餐厅的数据吗？
|
|||
|
|
- 有（缓存命中）→ 直接返回，耗时 5ms
|
|||
|
|
- 没有（缓存未命中）→ 查 Aurora 数据库 → 结果写入 Redis → 返回
|
|||
|
|
6. 响应经过 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 | 应对午餐/晚餐高峰 |
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 今天的小测验
|
|||
|
|
|
|||
|
|
1. 为什么这个架构同时用了 Aurora 和 DynamoDB 两种数据库？
|
|||
|
|
2. 如果不用 CloudFront，用户体验会有什么变化？
|
|||
|
|
3. 为什么"发通知"这个操作要用 SQS 异步处理，而不是下单时同步发送？
|
|||
|
|
4. 如果午餐高峰期流量突然暴涨 5 倍，这个架构的哪些部分会自动应对？
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 延伸阅读
|
|||
|
|
|
|||
|
|
- [AWS 架构中心](https://aws.amazon.com/architecture/)
|
|||
|
|
- [AWS Well-Architected Labs](https://wellarchitectedlabs.com/)
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 明天预告
|
|||
|
|
|
|||
|
|
进入第三阶段：安全与身份。明天深入学习 IAM 策略的编写——用精确的规则控制"谁能对什么资源做什么操作"。
|