# 第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 上实现微服务的最佳实践。