230 lines
6.8 KiB
Markdown
230 lines
6.8 KiB
Markdown
|
# 第30天：API Gateway——统一的 API 入口
|
|||
|
|
|
|||
|
|
## 今天你将学到什么
|
|||
|
|
|
|||
|
|
今天学习 API Gateway——AWS 的 API 管理服务。它是你后端服务的"大门"，负责接收客户端请求、验证身份、限制流量、路由到正确的后端服务。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 为什么需要 API Gateway
|
|||
|
|
|
|||
|
|
### 没有 API Gateway 的问题
|
|||
|
|
|
|||
|
|
假设你有一个微服务架构，有多个后端服务：
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
手机 APP 直接调用：
|
|||
|
|
→ 用户服务（端口 8001）
|
|||
|
|
→ 订单服务（端口 8002）
|
|||
|
|
→ 商品服务（端口 8003）
|
|||
|
|
→ 支付服务（端口 8004）
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**问题**：
|
|||
|
|
- 客户端需要知道每个服务的地址（耦合）
|
|||
|
|
- 每个服务都要自己实现认证、限流、日志（重复）
|
|||
|
|
- 服务地址变了，所有客户端都要更新
|
|||
|
|
- 没有统一的监控和管理
|
|||
|
|
|
|||
|
|
### 有 API Gateway 的世界
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
手机 APP → API Gateway（统一入口）
|
|||
|
|
├── /users/* → 用户服务
|
|||
|
|
├── /orders/* → 订单服务
|
|||
|
|
├── /products/* → 商品服务
|
|||
|
|
└── /payments/* → 支付服务
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**类比**：API Gateway 就像酒店的前台。客人（客户端）不需要知道每个部门（后端服务）在哪里，只需要告诉前台需要什么，前台帮你转接到正确的部门。前台还负责验证你的身份（房卡）、记录你的请求。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## API Gateway 能做什么
|
|||
|
|
|
|||
|
|
| 功能 | 说明 | 好处 |
|
|||
|
|
|------|------|------|
|
|||
|
|
| 请求路由 | 根据 URL 路径转发到不同后端 | 客户端只需要一个地址 |
|
|||
|
|
| 身份认证 | 验证 API 密钥、JWT Token、IAM 签名 | 后端不用重复实现认证 |
|
|||
|
|
| 请求限流 | 限制每秒请求数，防止滥用 | 保护后端不被压垮 |
|
|||
|
|
| 请求转换 | 修改请求/响应的格式 | 适配不同客户端需求 |
|
|||
|
|
| 缓存 | 缓存 API 响应 | 减少后端压力，加速响应 |
|
|||
|
|
| CORS | 处理跨域请求 | 前端可以直接调用 API |
|
|||
|
|
| API 版本管理 | 支持 v1、v2 等多个版本共存 | 平滑升级，不影响老用户 |
|
|||
|
|
| 监控 | 请求量、延迟、错误率 | 了解 API 使用情况 |
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## AWS API Gateway 的三种类型
|
|||
|
|
|
|||
|
|
| 类型 | 适合场景 | 特点 |
|
|||
|
|
|------|----------|------|
|
|||
|
|
| REST API | 功能最全的 RESTful API | 支持所有功能，价格稍高 |
|
|||
|
|
| HTTP API | 简单的 HTTP 代理 | 功能较少但便宜 70%，延迟更低 |
|
|||
|
|
| WebSocket API | 实时双向通信 | 聊天、实时通知、游戏 |
|
|||
|
|
|
|||
|
|
**选择建议**：
|
|||
|
|
- 大多数场景用 HTTP API（便宜、快）
|
|||
|
|
- 需要请求转换、缓存、API 密钥计划等高级功能用 REST API
|
|||
|
|
- 需要实时推送用 WebSocket API
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## API Gateway + Lambda：无服务器 API
|
|||
|
|
|
|||
|
|
最经典的组合：API Gateway 接收请求，Lambda 处理逻辑。
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
客户端 → API Gateway → Lambda 函数 → DynamoDB
|
|||
|
|
→ S3
|
|||
|
|
→ 其他服务
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**优势**：
|
|||
|
|
- 完全无服务器，不需要管理任何机器
|
|||
|
|
- 按请求付费，没有请求就不花钱
|
|||
|
|
- 自动扩展，能应对突发流量
|
|||
|
|
|
|||
|
|
**适合**：
|
|||
|
|
- 中小型 API
|
|||
|
|
- 流量不稳定的应用
|
|||
|
|
- 快速原型开发
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 认证与授权
|
|||
|
|
|
|||
|
|
API Gateway 支持多种认证方式：
|
|||
|
|
|
|||
|
|
### 方式一：API 密钥
|
|||
|
|
|
|||
|
|
最简单的方式。给每个客户端分配一个 API Key。
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
客户端请求头：x-api-key: abc123xyz
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
适合：内部服务间调用、简单的第三方集成。
|
|||
|
|
|
|||
|
|
### 方式二：Cognito 用户池
|
|||
|
|
|
|||
|
|
AWS 的用户管理服务。用户登录后获得 JWT Token，API Gateway 自动验证。
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
用户登录 → Cognito 返回 Token → 客户端带着 Token 请求 API → API Gateway 验证 Token
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
适合：面向终端用户的应用（APP、网站）。
|
|||
|
|
|
|||
|
|
### 方式三：Lambda 授权器
|
|||
|
|
|
|||
|
|
自定义认证逻辑。API Gateway 收到请求后，先调用一个 Lambda 函数验证身份。
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
客户端请求 → API Gateway → Lambda 授权器（验证 Token）
|
|||
|
|
├── 验证通过 → 转发到后端
|
|||
|
|
└── 验证失败 → 返回 401
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
适合：需要自定义认证逻辑（比如验证自己系统的 Token）。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 限流与配额
|
|||
|
|
|
|||
|
|
### 为什么要限流
|
|||
|
|
|
|||
|
|
- 防止恶意用户刷接口
|
|||
|
|
- 防止 bug 导致的无限循环调用
|
|||
|
|
- 保护后端服务不被压垮
|
|||
|
|
- 公平分配资源给所有用户
|
|||
|
|
|
|||
|
|
### API Gateway 的限流机制
|
|||
|
|
|
|||
|
|
| 级别 | 说明 | 举例 |
|
|||
|
|
|------|------|------|
|
|||
|
|
| 账户级别 | 整个账户的默认限制 | 10,000 请求/秒 |
|
|||
|
|
| API 级别 | 单个 API 的限制 | 5,000 请求/秒 |
|
|||
|
|
| 方法级别 | 单个接口的限制 | /login 限制 100 请求/秒 |
|
|||
|
|
| 客户端级别 | 单个 API Key 的限制 | 每个客户端 1,000 请求/秒 |
|
|||
|
|
|
|||
|
|
### 使用计划（Usage Plan）
|
|||
|
|
|
|||
|
|
可以为不同的客户端设置不同的配额：
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
免费用户：每天 1,000 次调用，每秒最多 10 次
|
|||
|
|
付费用户：每天 100,000 次调用，每秒最多 100 次
|
|||
|
|
企业用户：无限调用，每秒最多 1,000 次
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## API 版本管理
|
|||
|
|
|
|||
|
|
### 为什么需要版本
|
|||
|
|
|
|||
|
|
你的 API 已经有很多客户端在用了。现在要改接口格式，但不能让老客户端突然不能用。
|
|||
|
|
|
|||
|
|
### 实现方式
|
|||
|
|
|
|||
|
|
**方式一：URL 路径版本**
|
|||
|
|
```
|
|||
|
|
https://api.example.com/v1/users ← 老版本
|
|||
|
|
https://api.example.com/v2/users ← 新版本
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**方式二：阶段（Stage）**
|
|||
|
|
|
|||
|
|
API Gateway 支持多个"阶段"，每个阶段是一个独立的部署：
|
|||
|
|
```
|
|||
|
|
https://api.example.com/dev/users ← 开发环境
|
|||
|
|
https://api.example.com/test/users ← 测试环境
|
|||
|
|
https://api.example.com/prod/users ← 生产环境
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 实际架构示例
|
|||
|
|
|
|||
|
|
### 一个完整的无服务器后端
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
移动 APP / Web 前端
|
|||
|
|
↓
|
|||
|
|
CloudFront（缓存静态资源）
|
|||
|
|
↓
|
|||
|
|
API Gateway（API 入口）
|
|||
|
|
├── GET /products → Lambda → DynamoDB（查询商品）
|
|||
|
|
├── POST /orders → Lambda → DynamoDB + SQS（创建订单）
|
|||
|
|
├── GET /users/me → Lambda → RDS（查询用户信息）
|
|||
|
|
└── POST /upload → Lambda → S3（上传文件）
|
|||
|
|
↓
|
|||
|
|
Cognito（用户认证）
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**成本**：如果每天 10 万次 API 调用，月费大约只有几美元。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 今天的小测验
|
|||
|
|
|
|||
|
|
1. API Gateway 解决了什么问题？没有它会怎样？
|
|||
|
|
2. REST API 和 HTTP API 的区别是什么？怎么选？
|
|||
|
|
3. API Gateway 支持哪些认证方式？各自适合什么场景？
|
|||
|
|
4. 为什么需要 API 限流？可以在哪些级别设置限流？
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 延伸阅读
|
|||
|
|
|
|||
|
|
- [API Gateway 开发者指南](https://docs.aws.amazon.com/apigateway/latest/developerguide/)
|
|||
|
|
- [API Gateway REST API vs HTTP API](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-vs-rest.html)
|
|||
|
|
- [使用 Cognito 保护 API](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html)
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 明天预告
|
|||
|
|
|
|||
|
|
明天学习微服务架构——如何把一个大应用拆分成多个小服务，以及 AWS 上实现微服务的最佳实践。
|