2. OpenAPI 网关基础：定义与核心功能回顾
在深入重试与超时联动处理之前，有必要先回顾 OpenAPI 网关的基础定义与三大核心功能。网关作为 API 流量的统一入口，其路由、限流、鉴权能力是后续所有高级特性的基石。
2.1 网关的定义与定位
OpenAPI 网关（API Gateway）是位于客户端与后端服务集群之间的反向代理层，负责接收所有外部 API 请求，并按照预定义的策略进行转发、过滤与治理。它解决了微服务架构中以下典型问题：
- 客户端耦合：客户端无需感知后端服务的拆分细节，只需与网关交互。
- 横切关注点：将鉴权、限流、日志、监控等通用逻辑从业务服务中抽离，统一在网关层实现。
- 协议转换：支持 HTTP/HTTPS、gRPC、WebSocket 等多种协议的适配与转换。
关键认知：网关不是简单的反向代理，而是 API 治理的策略执行点。重试与超时联动处理正是网关在“可靠性治理”维度的重要体现。
2.2 核心功能一：路由（Routing）
路由是网关最基础的功能，负责将客户端请求按照规则分发到对应的后端服务实例。路由规则通常包含以下要素：
| 路由要素 | 说明 | 示例 |
|---|---|---|
| 路径匹配 | 根据请求 URI 路径进行匹配 | /api/orders/** → 订单服务 |
| 方法匹配 | 根据 HTTP 方法（GET/POST/PUT/DELETE）过滤 | POST /api/users → 创建用户 |
| Header 匹配 | 根据请求头中的特定字段路由 | X-Version: v2 → 新版服务 |
| 权重路由 | 按比例分发流量到不同版本或集群 | v1: 90%, v2: 10%（灰度发布） |
重试关联点：路由规则决定了重试请求的目标地址。如果路由策略未正确配置（如未排除已熔断实例），重试可能加剧故障。
2.3 核心功能二：限流（Rate Limiting）
限流用于控制单位时间内允许通过的请求数量，防止突发流量冲垮后端服务。常见的限流算法包括：
- 令牌桶（Token Bucket）：以固定速率向桶中添加令牌，请求需获取令牌才能通过。允许一定程度的突发流量。
- 漏桶（Leaky Bucket）：请求以固定速率流出，超出桶容量的请求被丢弃。平滑流量效果最好。
- 滑动窗口（Sliding Window）：基于时间窗口内的请求计数进行限流，精度较高，但内存开销略大。
| 算法 | 突发处理 | 平滑度 | 实现复杂度 | 适用场景 |
|---|---|---|---|---|
| 令牌桶 | 支持 | 中等 | 低 | 允许短时突发的业务 |
| 漏桶 | 不支持 | 高 | 低 | 严格平滑流量的场景 |
| 滑动窗口 | 有限支持 | 较高 | 中 | 需要精确计数的场景 |
重试与限流的冲突：重试请求会消耗限流配额。如果重试策略未与限流联动，可能导致正常请求被限流拒绝，而重试请求却占用了配额。这是本课程后续要解决的关键问题之一。
2.4 核心功能三：鉴权（Authentication & Authorization）
鉴权确保只有合法用户才能访问受保护的 API 资源。网关层鉴权通常分为两个阶段：
- 身份认证（Authentication）：验证请求方的身份，常见方式包括 JWT 校验、OAuth2 Token 校验、API Key 校验。
- 权限授权（Authorization）：确认已认证的用户是否有权执行当前操作，通常基于 RBAC（基于角色的访问控制）或 ABAC（基于属性的访问控制）。
网关鉴权的典型流程如下：
鉴权与重试的交互：对于因 Token 过期导致的 401 错误，重试不应简单重复原始请求，而应触发 Token 刷新流程。本课程后续会讨论如何在重试策略中识别并处理鉴权类错误。
2.5 三大核心功能的协同关系
路由、限流、鉴权并非独立运行，它们在网关内部形成一条有序的请求处理链：
- 请求到达：网关接收客户端请求。
- 鉴权拦截：首先进行身份认证与权限校验，失败则直接拒绝。
- 限流检查：通过鉴权后，检查是否超出限流配额，超出则返回 429 Too Many Requests。
- 路由转发：根据路由规则将请求转发到目标后端服务。
- 结果返回：将后端响应返回给客户端，或触发重试/熔断等后续处理。
理解这三者的协同关系，是后续设计重试与超时联动策略的前提——重试请求必须重新经过限流检查，且不能绕过鉴权逻辑。