248 lines
7.8 KiB
Markdown
248 lines
7.8 KiB
Markdown
# 第32天：应用架构综合实战——设计一个 SaaS 平台
|
||
|
||
## 今天你将学到什么
|
||
|
||
今天是第四阶段的收尾。我们用一个完整的 SaaS（软件即服务）平台案例，把容器、CI/CD、API Gateway、Step Functions、微服务等知识串联起来。
|
||
|
||
---
|
||
|
||
## 项目背景：在线协作文档平台
|
||
|
||
假设你要做一个类似"腾讯文档"的简化版平台：
|
||
- 用户可以创建、编辑、分享文档
|
||
- 支持多人实时协作编辑
|
||
- 支持文档导出为 PDF
|
||
- 有团队管理和权限控制
|
||
- 需要支持百万级用户
|
||
|
||
---
|
||
|
||
## 整体架构
|
||
|
||
```
|
||
Web 前端 / 移动端
|
||
↓
|
||
CloudFront（静态资源 + API 加速）
|
||
↓
|
||
API Gateway（REST API 入口）
|
||
↓
|
||
┌─────────────────────────────────────────────────┐
|
||
│ ECS Fargate 集群 │
|
||
│ │
|
||
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
|
||
│ │ 用户服务 │ │ 文档服务 │ │ 团队服务 │ │
|
||
│ └──────────┘ └──────────┘ └──────────┘ │
|
||
│ ┌──────────┐ ┌──────────┐ │
|
||
│ │ 权限服务 │ │ 搜索服务 │ │
|
||
│ └──────────┘ └──────────┘ │
|
||
└─────────────────────────────────────────────────┘
|
||
↓
|
||
┌─────────────────────────────────────────────────┐
|
||
│ 数据层 │
|
||
│ Aurora（用户、团队、权限） │
|
||
│ DynamoDB（文档内容、版本历史） │
|
||
│ ElastiCache Redis（会话、协作状态） │
|
||
│ S3（文档附件、导出的 PDF） │
|
||
│ OpenSearch（全文搜索） │
|
||
└─────────────────────────────────────────────────┘
|
||
|
||
异步处理：
|
||
EventBridge → Step Functions → Lambda
|
||
（文档导出、通知发送、数据分析）
|
||
|
||
实时协作：
|
||
API Gateway WebSocket → Lambda → DynamoDB + Redis
|
||
```
|
||
|
||
---
|
||
|
||
## 各服务职责
|
||
|
||
### 用户服务
|
||
- 注册、登录、个人信息管理
|
||
- 集成 Cognito 做身份认证
|
||
- 数据库：Aurora（用户表）
|
||
|
||
### 文档服务
|
||
- 创建、读取、更新、删除文档
|
||
- 管理文档版本历史
|
||
- 数据库：DynamoDB（文档内容，支持高频读写）
|
||
|
||
### 团队服务
|
||
- 创建团队、邀请成员、管理角色
|
||
- 数据库：Aurora（团队和成员关系）
|
||
|
||
### 权限服务
|
||
- 判断用户对某个文档有没有权限
|
||
- 缓存：Redis（权限判断需要极快响应）
|
||
|
||
### 搜索服务
|
||
- 全文搜索文档内容和标题
|
||
- 引擎：OpenSearch（Elasticsearch 托管版）
|
||
|
||
---
|
||
|
||
## 关键流程设计
|
||
|
||
### 流程一：用户编辑文档
|
||
|
||
```
|
||
1. 用户打开文档
|
||
→ API Gateway → 权限服务（检查权限）→ 文档服务（获取内容）
|
||
|
||
2. 用户编辑
|
||
→ WebSocket 连接 → Lambda → DynamoDB（保存变更）
|
||
→ Redis（广播给其他协作者）
|
||
|
||
3. 自动保存
|
||
→ 每 5 秒将变更批量写入 DynamoDB
|
||
→ 保留版本历史（最近 100 个版本）
|
||
```
|
||
|
||
### 流程二：文档导出 PDF（Step Functions）
|
||
|
||
```
|
||
用户点击"导出 PDF"
|
||
↓
|
||
API Gateway → Lambda（创建导出任务）→ 返回任务 ID 给用户
|
||
↓
|
||
Step Functions 工作流启动：
|
||
↓
|
||
获取文档内容（Task）
|
||
↓
|
||
渲染为 PDF（Task，可能需要 30 秒）
|
||
↓
|
||
上传到 S3（Task）
|
||
↓
|
||
生成下载链接（Task）
|
||
↓
|
||
通知用户"PDF 已就绪"（Task → SNS → 推送通知）
|
||
```
|
||
|
||
为什么用 Step Functions？因为 PDF 渲染可能需要较长时间，不适合让用户同步等待。
|
||
|
||
### 流程三：新用户注册
|
||
|
||
```
|
||
用户注册
|
||
↓
|
||
Cognito 创建用户
|
||
↓
|
||
EventBridge 发布"用户注册"事件
|
||
↓
|
||
├── Lambda：创建默认工作空间
|
||
├── Lambda：发送欢迎邮件（SES）
|
||
├── Lambda：创建示例文档
|
||
└── Lambda：记录注册统计
|
||
```
|
||
|
||
---
|
||
|
||
## CI/CD 流水线
|
||
|
||
```
|
||
开发者推送代码（GitHub）
|
||
↓
|
||
CodePipeline 触发
|
||
↓
|
||
CodeBuild：
|
||
- 运行单元测试
|
||
- 构建 Docker 镜像
|
||
- 推送到 ECR
|
||
- 运行安全扫描
|
||
↓
|
||
部署到 Staging 环境：
|
||
- 更新 ECS 服务
|
||
- 运行集成测试
|
||
- 运行 E2E 测试
|
||
↓
|
||
人工审批（团队负责人确认）
|
||
↓
|
||
部署到 Production：
|
||
- ECS 蓝绿部署
|
||
- 金丝雀发布（5% → 25% → 100%）
|
||
- 自动回滚（如果错误率上升）
|
||
```
|
||
|
||
每个微服务有自己独立的流水线，可以独立部署。
|
||
|
||
---
|
||
|
||
## 扩展性设计
|
||
|
||
| 组件 | 扩展方式 | 触发条件 |
|
||
|------|----------|----------|
|
||
| ECS 服务 | 自动扩展任务数 | CPU > 70% 或请求队列增长 |
|
||
| DynamoDB | 自动扩展读写容量 | 使用率 > 70% |
|
||
| Aurora | 增加只读副本 | 读取延迟 > 100ms |
|
||
| Redis | 增加分片 | 内存使用 > 80% |
|
||
| Lambda | 自动（无需配置） | 并发请求增加 |
|
||
|
||
---
|
||
|
||
## 成本优化策略
|
||
|
||
| 策略 | 节省 | 实现方式 |
|
||
|------|------|----------|
|
||
| Fargate Spot | 最多 70% | 非关键服务使用 Spot 容量 |
|
||
| DynamoDB 按需模式 | 避免过度预置 | 流量不稳定的表用按需模式 |
|
||
| S3 生命周期 | 存储费用 | 30 天前的版本转到低频存储 |
|
||
| CloudFront 缓存 | 减少源站请求 | 静态资源缓存 24 小时 |
|
||
| Reserved Capacity | 最多 60% | Aurora 和 Redis 用预留实例 |
|
||
|
||
---
|
||
|
||
## 监控与告警
|
||
|
||
```
|
||
CloudWatch Dashboard（统一视图）：
|
||
├── 业务指标：活跃用户数、文档创建数、API 调用量
|
||
├── 性能指标：API 延迟 P99、错误率、数据库连接数
|
||
├── 资源指标：CPU、内存、磁盘使用率
|
||
└── 成本指标：每日花费、各服务占比
|
||
|
||
告警规则：
|
||
├── API 错误率 > 1% → 通知开发团队（Slack）
|
||
├── P99 延迟 > 2s → 通知运维团队
|
||
├── 数据库连接数 > 80% → 自动扩展 + 通知
|
||
└── 月度成本超预算 20% → 通知管理层
|
||
```
|
||
|
||
---
|
||
|
||
## 架构决策总结
|
||
|
||
| 决策 | 选择 | 原因 |
|
||
|------|------|------|
|
||
| 服务运行 | ECS Fargate | 不想管服务器，按需付费 |
|
||
| API 入口 | API Gateway | 统一认证、限流、监控 |
|
||
| 实时协作 | WebSocket + Redis | 低延迟双向通信 |
|
||
| 文档存储 | DynamoDB | 高频读写、灵活 schema |
|
||
| 用户数据 | Aurora | 关系型数据、复杂查询 |
|
||
| 异步处理 | EventBridge + Step Functions | 解耦、可视化、错误处理 |
|
||
| 搜索 | OpenSearch | 全文搜索、模糊匹配 |
|
||
| 部署 | 蓝绿 + 金丝雀 | 零停机、低风险 |
|
||
|
||
---
|
||
|
||
## 今天的小测验
|
||
|
||
1. 为什么文档内容用 DynamoDB 而不是 Aurora？
|
||
2. 文档导出 PDF 为什么用 Step Functions 而不是同步处理？
|
||
3. 这个架构中，哪些部分可以独立扩展？
|
||
4. 如果某个微服务出了 bug，对其他服务有什么影响？
|
||
|
||
---
|
||
|
||
## 延伸阅读
|
||
|
||
- [AWS SaaS 架构指南](https://docs.aws.amazon.com/whitepapers/latest/saas-architecture-fundamentals/saas-architecture-fundamentals.html)
|
||
- [AWS 无服务器应用模型](https://docs.aws.amazon.com/serverless-application-model/)
|
||
- [AWS 架构中心](https://aws.amazon.com/architecture/)
|
||
|
||
---
|
||
|
||
## 明天预告
|
||
|
||
进入第五阶段：监控与运维。明天学习 CloudWatch——AWS 的监控核心。了解如何监控你的应用和基础设施，设置告警，在问题发生前就发现它。
|