wangqifan/aws-doc

Fork 0

wangqifan a80067d684 all

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

6.8 KiB

Raw Blame History

第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 调用，月费大约只有几美元。

今天的小测验

API Gateway 解决了什么问题？没有它会怎样？
REST API 和 HTTP API 的区别是什么？怎么选？
API Gateway 支持哪些认证方式？各自适合什么场景？
为什么需要 API 限流？可以在哪些级别设置限流？

明天预告

明天学习微服务架构——如何把一个大应用拆分成多个小服务，以及 AWS 上实现微服务的最佳实践。

6.8 KiB Raw Blame History Unescape Escape