# 第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 策略的编写——用精确的规则控制"谁能对什么资源做什么操作"。