使用 AWS API Gateway 构建无服务器 API | API 101 专栏 | 支流科技

关键要点

AWS API Gateway 是无服务器应用程序的 中央"前门"，为 REST、HTTP 和 WebSocket API 提供完全托管的创建、发布和安全保障。
它通过将后端（如 Lambda）与前端解耦来简化架构，实现 独立扩展、稳健的 安全执行 和高级的 API 生命周期管理。
为了获得最佳的成本和性能，对于更简单的高容量用例 选择 HTTP API，当你需要 API 密钥、请求验证和自定义授权方等高级功能时 选择 REST API。
使用 IAM、Lambda 授权方和资源策略等内置功能实施 "安全第一" 的设计是生产 API 的基础最佳实践。

什么是 AWS API Gateway？

在现代应用程序架构中，API 已成为客户端与后端服务交互的基本"前门"。AWS API Gateway 是一个完全托管的 AWS 服务，为开发者提供在任何规模下创建、发布、维护、监控和保护这些门所需的全面工具。它支持三种主要的 API 类型，每种都为特定的通信模式和使用场景而设计。

HTTP API：这些被设计为 轻量级、低延迟且经济高效 的网关，用于基于 HTTP 的交互。它们是构建向 AWS Lambda 或公共 HTTP 后端等代理请求的无状态 API 的理想选择。它们支持基于 JWT 的授权并针对性能进行了优化。
REST API：这些是功能齐全的 RESTful API，提供最广泛的功能集。它们对 API 生命周期的每个方面提供细粒度控制，包括请求/响应转换、API 密钥、使用计划、每个客户端的节流以及与 AWS Web 应用程序防火墙（WAF）的集成。这使它们适合复杂的企业级应用程序。
WebSocket API：专为实时双向通信而设计，WebSocket API 维护客户端和服务器之间的持久连接。这非常适合聊天应用程序、实时仪表板或实时通知等用例，其中服务器需要立即向已连接的客户端推送更新。

API Gateway 的核心价值在于其作为强大抽象层的角色。它位于客户端（移动应用、Web 浏览器、其他服务）和后台逻辑（通常是 AWS Lambda 函数）之间。这种解耦允许你在不中断客户端应用程序的情况下修改、扩展或完全替换后端服务。它还充当一个集中式点，用于执行安全性、管理流量和监控使用——这些功能否则需要构建到每个后端服务中。

为什么在无服务器架构中选择 AWS API Gateway？

采用 AWS API Gateway，特别是在与 AWS Lambda 一起的无服务器环境中，是一个提供明确成本、安全性和开发者敏捷性优势的战略决策。

完全托管和无服务器：API Gateway 消除了管理 API 基础设施的繁重工作。无需配置、修补或扩展服务器。该服务自动扩展以处理数十万个并发 API 调用，并且你只需为收到的 API 调用和传输出的数据付费。
经济高效的性能：API 类型之间的选择直接影响成本。HTTP API 明显比 REST API 便宜，使其成为大多数无服务器应用程序的绝佳默认选择。例如，在美国东部（弗吉尼亚北部）区域，HTTP API 每月前 3 亿次请求的费用为每百万 1.00 美元，而 REST API 为每百万 3.50 美元。结合其更低的延迟，这使 HTTP API 成为高容量简单代理集成的最佳选择。
整合的安全层：API Gateway 充当 安全策略的集中式执行点，这是纵深防御战略的基石。它支持多种分层的授权机制：
- IAM 角色和策略：用于保护 AWS 服务之间的访问（例如，服务到服务调用）。
- Lambda 授权方：用于使用你自己的代码实现复杂的自定义授权逻辑（例如，验证自定义令牌或检查数据库中的权限）。
- Amazon Cognito 和 JWT 授权方：用于管理 Web 和移动应用程序中的用户认证和授权。
- 资源策略：用于基于源 IP 地址、AWS 账户或 VPC 端点控制访问，这对于不暴露给公共 Internet 的 私有 API 尤其重要。
加速开发生命周期：API Gateway 简化了 API 开发过程。你可以快速 部署多个阶段（例如，dev、test、prod）的 API，使用 Amazon CloudWatch 启用详细的日志记录和监控，甚至 生成客户端 SDK 以使开发者更容易消费你的 API。这种集成工具使团队能够专注于业务逻辑而非基础设施。

1graph TD
2    classDef client fill:#e3f2fd,stroke:#1565c0
3    classDef gateway fill:#f3e5f5,stroke:#7b1fa2
4    classDef lambda fill:#e8f5e9,stroke:#388e3c
5    classDef data fill:#fff3e0,stroke:#f57c00
6    classDef notification fill:#ffebee,stroke:#d32f2f
7
8    subgraph "📱 客户端"
9        C1[Web 应用]:::client
10        C2[移动应用]:::client
11        C3[合作伙伴 API]:::client
12    end
13
14    C1 & C2 & C3 --> Gateway[AWS API Gateway<br/><small>认证 • 速率限制 • 路由</small>]:::gateway
15
16    Gateway --> Lambda1[用户服务 Lambda]:::lambda
17    Gateway --> Lambda2[订单服务 Lambda]:::lambda
18
19    Lambda1 --> DB[(DynamoDB)]:::data
20    Lambda2 --> DB
21    Lambda2 --> S3[(S3 存储)]:::data
22
23    Lambda2 --> Notification[发送通知]:::notification
24    Notification --> Ext[外部系统]
25
26    linkStyle 6 stroke-dasharray: 5 5

如何构建和优化无服务器 API

构建一个稳健、生产就绪的无服务器 API 需要做的不仅仅是连接 Lambda 函数。它需要在 API 设计、集成模式、安全性和性能优化方面做出深思熟虑的决策。

1. 基础设置和集成

经典的无服务器模式涉及 API Gateway 接收 HTTP 请求并将其路由到 Lambda 函数。AWS 为这个确切场景提供了详细的教程，创建一个对 Amazon DynamoDB 表执行 CRUD 操作的 REST API。

这里的关键决策是 集成类型：

Lambda 代理集成（大多数情况下推荐）：API Gateway 将整个 HTTP 请求（请求头、路径、请求体等）直接作为结构化事件对象传递给你的 Lambda 函数。你的函数负责解析此输入并返回正确格式化的响应。这种方法提供最大的灵活性和更简单的网关配置。
Lambda 非代理集成：在这里，API Gateway 被配置为在向 Lambda 发送之前将传入请求转换为自定义格式。这对于适配遗留的载荷格式很有用，但会增加网关设置的复杂性。

2. 战略性 API 设计和选择

你的第一个也是最重要的设计选择是选择正确的 API 类型。这个决策平衡了功能需求与成本和复杂性。

1flowchart TD
2A[开始：新的 API Gateway API] --> B{需要实时、<br/>双向通信？};
3B -- 是 --> C[使用 WebSocket API];
4
5B -- 否 --> D{需要高级功能？};
6D -- 是 --> E[使用 REST API];
7
8D -- 否 --> F[使用 HTTP API];
9
10C --> G[示例：<br/>聊天、通知、实时源];
11E --> H[示例：<br/>API 密钥、使用计划、<br/>请求验证、WAF];
12F --> I[示例：<br/>无服务器微服务、<br/>高容量公共 API];

在以下情况使用 HTTP API：你正在构建一个新的、简单的 API，其中成本和延迟是主要关注点。它们非常适合无服务器微服务和单页应用程序。

在以下情况使用 REST API：你需要特定的、高级的功能。关键的区别包括：

API 密钥和使用计划：用于通过你的 API 赚钱或按客户端跟踪使用情况。
请求验证：使用模型在请求到达 Lambda 函数之前验证传入请求是否符合定义的规范。
边缘优化端点：通过 AWS CloudFront CDN 实现全球延迟降低。
私有端点：创建只能从你的 Amazon VPC 内部访问的 API。

3. 实施生产级安全性

遵循 AWS 架构良好的安全原则是不容妥协的。分层实施这些：

始终使用 HTTPS：API Gateway 对所有端点强制使用 TLS 加密。对于受监管的工作负载，使用 增强的安全策略（例如，SecurityPolicy_TLS13_1_3）来强制执行现代密码套件和 TLS 版本。
应用最小权限原则：无论是为 Lambda 函数使用 IAM 角色还是为用户使用 IAM 策略，都只授予必要的最小权限。例如，一个写入 DynamoDB 的 Lambda 函数不应该具有对不相关 S3 存储桶的读取权限。
尽早验证和授权：使用 API Gateway 内置的 请求验证 在边缘拒绝格式错误的请求。使用 Lambda 授权方 在请求被转发到业务逻辑后端之前验证 JWT 令牌或自定义逻辑。性能分析显示，虽然 Python 授权方的冷启动可能会增加约 750 毫秒，但这是罕见的情况，而热授权方增加的延迟可以忽略不计（约 10-30 毫秒）。
选择正确的端点类型：对于内部服务，使用 私有 API 端点。这些只能从你的 VPC 内部访问，大大减少你的公共攻击面。

4. 优化性能和成本

管理 Lambda 冷启动：冷启动是无服务器架构中的现实。性能数据显示，小函数的平均冷启动损失根据运行时（Python、Node.js、Go）从 130-470 毫秒不等。通过以下方式缓解：
- 配置并发：对于关键的低延迟函数，使用配置并发来保持函数初始化和热状态。
- 优化包大小：保持你的部署包精简。虽然较小的包通常有帮助，但运行时初始化比单独的包大小有更大的影响。
实施缓存：对于 REST API，启用 API 缓存 来存储端点响应。这大大降低了延迟和对后端 Lambda 函数的调用次数，提高了性能并降低了成本。
使用贪婪路径进行原型设计：对于初始开发或当你希望在单个 Lambda 函数中处理复杂的路由逻辑时，使用像 {proxy+} 这样的 贪婪路径变量。这会捕获特定资源下的所有请求路径并将它们发送到一个集成，从而简化初始设置。
调整 Lambda 内存大小：分配正确的内存对于性能和成本都至关重要。一项性能分析发现，对于许多真实世界的函数来说，1024 MB 是最佳的内存大小，平衡了执行速度和成本。始终测试你的特定函数以找到其自己的最佳配置。避免为执行任何有意义工作的函数使用 128 MB，因为这通常会导致性能不佳。

结论：现代应用程序的战略推动者

AWS API Gateway 远不只是一个简单的 HTTP 路由器；它是 现代无服务器应用程序开发的战略推动者。通过为你的后端服务提供一个稳健的、完全托管的外观，它允许开发团队卸载关键的关注，如流量管理、授权、监控和版本控制。HTTP 和 REST API 之间的选择使你能够将架构与技术需求和财务约束对齐，而 WebSocket 支持解锁了实时应用程序可能性的新领域。

掌握 API Gateway 涉及将其作为 API 的中央控制点的角色内化。这意味着利用其深度安全集成来构建可防御的系统，使用其部署阶段来促进敏捷开发生命周期，并应用缓存和正确的 Lambda 配置等性能优化。当遵循这些最佳实践实施时，AWS API Gateway 提供了构建定义当今数字格局的敏捷、经济高效应用程序所需的坚实、可扩展且安全的基础。