wangqifan/aws-doc

Fork 0

wangqifan a80067d684 all

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

7.7 KiB

Raw Permalink Blame History

第39天：实战项目——从零设计一个云原生应用

今天你将学到什么

今天是综合实战日。我们从零开始设计一个完整的云原生应用——"智能笔记"平台，综合运用前面学到的所有知识。这个练习帮你把零散的知识点串联成完整的架构思维。

项目需求

产品描述：智能笔记平台

一个支持 AI 辅助的笔记应用：

用户可以创建、编辑、组织笔记
支持图片和文件附件
AI 功能：自动摘要、智能标签、相关笔记推荐
支持笔记分享和协作
支持全文搜索
移动端和 Web 端

非功能需求

需求	目标
可用性	99.9%（月停机 < 44 分钟）
响应时间	API P99 < 500ms
用户规模	初期 1 万用户，目标 100 万用户
数据安全	所有数据加密，符合隐私法规
成本	初期月费 < $500

架构设计过程

第一步：识别核心功能模块

1. 用户管理（注册、登录、个人设置）
2. 笔记 CRUD（创建、读取、更新、删除）
3. 文件管理（上传、下载附件）
4. AI 处理（摘要、标签、推荐）
5. 搜索（全文搜索笔记内容）
6. 分享与协作（分享链接、协作编辑）
7. 通知（新分享、AI 处理完成）

第二步：选择技术方案

模块	方案	原因
用户管理	Cognito	开箱即用，支持社交登录，免运维
笔记 API	API Gateway + Lambda	无服务器，按需付费，初期成本低
笔记存储	DynamoDB	灵活 schema，毫秒响应，自动扩展
文件存储	S3	无限容量，便宜，配合 CloudFront 加速
AI 处理	Lambda + SQS	异步处理，不阻塞用户操作
搜索	OpenSearch Serverless	全文搜索，无服务器模式省钱
实时协作	API Gateway WebSocket	双向通信，按连接付费
通知	SNS + 移动推送	多渠道通知
前端托管	S3 + CloudFront	全球加速，成本极低

第三步：画架构图

用户（Web / 移动端）
        ↓
CloudFront
├── 静态资源 → S3（前端代码）
└── API 请求 → API Gateway
                    ↓
              ┌─── Cognito 认证
              ↓
        Lambda 函数层
        ├── 笔记服务 → DynamoDB（笔记数据）
        ├── 文件服务 → S3（附件）+ 预签名 URL
        ├── 搜索服务 → OpenSearch
        └── 分享服务 → DynamoDB（分享关系）

异步处理层：
  DynamoDB Stream → Lambda → SQS → AI 处理 Lambda
                                        ↓
                                  ├── 生成摘要（调用 AI API）
                                  ├── 提取标签
                                  └── 更新 DynamoDB + OpenSearch

实时协作：
  API Gateway WebSocket → Lambda → DynamoDB + 连接管理

详细设计

数据模型（DynamoDB）

笔记表（Notes）：
  PK: USER#<userId>
  SK: NOTE#<noteId>
  属性：title, content, tags, summary, createdAt, updatedAt

分享表（Shares）：
  PK: NOTE#<noteId>
  SK: SHARE#<shareId>
  属性：sharedWith, permission, createdAt

全局二级索引（GSI）：
  GSI1: 按更新时间排序（获取最近编辑的笔记）
  GSI2: 按标签查询（获取某个标签下的所有笔记）

API 设计

方法	路径	功能
POST	/notes	创建笔记
GET	/notes	获取笔记列表
GET	/notes/{id}	获取单个笔记
PUT	/notes/{id}	更新笔记
DELETE	/notes/{id}	删除笔记
POST	/notes/{id}/share	分享笔记
GET	/search?q=keyword	搜索笔记
POST	/upload	获取文件上传 URL

安全设计

认证：Cognito JWT Token
授权：Lambda 中验证用户只能访问自己的笔记
传输加密：HTTPS（CloudFront 强制）
存储加密：DynamoDB + S3 使用 KMS 加密
密钥管理：API 密钥存在 Secrets Manager
审计：CloudTrail 记录所有 API 调用

AI 处理流程（Step Functions）

笔记保存触发
    ↓
DynamoDB Stream → Lambda（判断是否需要 AI 处理）
    ↓
Step Functions 工作流：
    ↓
并行执行：
├── 生成摘要（Lambda → AI API）
├── 提取关键词标签（Lambda → AI API）
└── 计算相关笔记（Lambda → OpenSearch）
    ↓
合并结果
    ↓
更新 DynamoDB（写入摘要、标签、推荐）
    ↓
通知用户"AI 处理完成"（SNS → 推送）

运维设计

监控

CloudWatch Dashboard：
├── API 指标：请求量、延迟、错误率
├── Lambda：调用次数、执行时间、错误数
├── DynamoDB：读写容量、延迟、节流次数
└── 业务指标：活跃用户数、笔记创建数

告警：
├── API 错误率 > 1% → 通知开发团队
├── Lambda 执行时间 > 5s → 通知
├── DynamoDB 节流 > 0 → 自动扩容
└── 月费用 > $400 → 通知

CI/CD

GitHub → CodePipeline：
  ├── 前端流水线：构建 → 部署到 S3 → 刷新 CloudFront 缓存
  └── 后端流水线：测试 → 打包 → 部署 Lambda 函数（SAM/CDK）

成本估算（初期 1 万用户）

服务	用量估算	月费
Lambda	500 万次调用	$10
API Gateway	500 万次请求	$17
DynamoDB	按需模式，5GB 数据	$25
S3	50GB 文件	$2
CloudFront	100GB 流量	$9
Cognito	1 万用户	$0（5 万内免费）
OpenSearch Serverless	最小配置	$175
CloudWatch	基本监控	$10
其他	Secrets Manager、KMS	$5
总计		约 $253/月

满足 < $500 的预算要求。随着用户增长，DynamoDB 和 Lambda 会自动扩展，费用线性增长。

扩展到 100 万用户

当用户从 1 万增长到 100 万时，需要的调整：

组件	调整	原因
DynamoDB	自动扩展（无需操作）	按需模式自动处理
Lambda	提高并发限制	默认 1000 并发可能不够
OpenSearch	增加容量	搜索量增大
CloudFront	无需调整	自动全球扩展
缓存	添加 DAX 或 ElastiCache	减少 DynamoDB 读取压力
API Gateway	无需调整	自动扩展

无服务器架构的优势：大部分组件自动扩展，不需要提前规划容量。

从这个项目中学到什么

架构决策的思考过程

先确定需求：功能需求 + 非功能需求
选择架构风格：无服务器 vs 容器 vs 虚拟机
为每个模块选择服务：根据特点匹配最合适的服务
设计数据模型：根据访问模式选择数据库和表结构
设计安全方案：认证、授权、加密、审计
设计运维方案：监控、告警、CI/CD
估算成本：确保在预算内
规划扩展：考虑未来增长

今天的小测验

为什么这个项目选择无服务器架构而不是容器？
AI 处理为什么要异步执行而不是同步？
为什么笔记数据用 DynamoDB 而不是 RDS？
如果搜索功能的成本太高，有什么替代方案？

明天预告

明天是最后一天：持续学习指南。了解学完这个课程后如何继续深入学习，保持技术更新，以及 AWS 社区资源。

7.7 KiB Raw Permalink Blame History Unescape Escape