3. API 网关基础：常见网关对比与请求生命周期
API 网关是云原生架构中流量入口的核心组件，负责请求路由、认证、限流、协议转换与可观测性。在 OPA 集成场景下，网关的延迟特性直接影响策略执行的端到端性能。本节从主流网关对比与请求生命周期两个维度建立基础认知。
3.1 主流 API 网关对比：Kong、Envoy、APISIX
当前社区与生产环境中最常用的三类网关分别为 Kong（基于 OpenResty/Nginx）、Envoy（C++ 实现，Istio 数据面默认）和 Apache APISIX（基于 OpenResty，但架构更现代）。下表从关键维度进行横向对比：
| 对比维度 | Kong | Envoy | APISIX |
|---|---|---|---|
| 核心语言 | Lua (OpenResty) | C++ | Lua + 多语言 Plugin Runner |
| 配置管理 | 数据库驱动（PostgreSQL/Cassandra） | xDS 协议（控制面下发） | ETCD 驱动 + Admin API |
| 插件扩展 | Lua 插件，支持 Go/JS 外部插件 | Lua (LuaJIT) / WASM / C++ Filter | Lua 原生 + Java/Go/Python Runner |
| 热加载 | Reload 或 DB 轮询 | 热更新（Listener 级别） | ETCD watch 实时热更新 |
| 延迟基准 | 中等（约 2-5ms 额外延迟） | 低（约 0.5-2ms） | 低（约 1-3ms） |
| OPA 集成方式 | 自定义插件 / OPA Kong Plugin | External Authorization Filter | opa-plugin / 自定义 Runner |
| 多集群支持 | Kong Mesh / 手动联邦 | 原生 xDS 多集群 | ETCD 集群 + 控制面高可用 |
选型建议： 若团队已有 Nginx/OpenResty 技术栈且需要丰富插件生态，Kong 是稳妥选择；若追求极致延迟与 Service Mesh 原生集成，Envoy 为首选；若需要高性能 + 实时热更新 + 多语言扩展，APISIX 在云原生场景下表现突出。
3.2 网关请求生命周期：从入站到出站
无论使用哪种网关，请求的生命周期都遵循一套通用阶段模型。理解每个阶段的耗时分布，是延迟诊断与 OPA 策略插入点分析的基础。
核心概念： 请求生命周期 = 连接建立 + 请求解析 + 路由匹配 + 插件链执行 + 上游转发 + 响应处理。OPA 策略通常嵌入在“插件链执行”阶段的认证/授权子阶段。
3.3 各阶段延迟分解与 OPA 集成点
将生命周期阶段与延迟指标对应，可以快速定位 OPA 集成后的瓶颈位置：
- 连接建立（T1）： 包含 TCP 握手、TLS 协商。若启用 mTLS，握手延迟增加 1-3 RTT。OPA 不参与此阶段。
- 请求解析（T2）： 解码 HTTP Header/Body。大 Body 或大量 Header 会显著增加解析时间。OPA 策略若需要解析 Body（如 JWT 或 JSON 校验），此阶段可能被复用。
- 路由匹配（T3）： 根据 Host/Path/Header 查找匹配 Route。路由表规模（千级 vs 万级）影响匹配耗时。OPA 不直接参与。
- 插件链执行（T4）： 核心延迟敏感区。典型顺序为：限流 → 认证 → OPA 授权 → 日志。OPA 查询延迟（含 Rego 编译 + 数据加载 + 评估）直接累加在此阶段。建议开启 OPA 缓存与 Partial Evaluation。
- 上游转发（T5）： 包含连接池获取、负载均衡、上游 TCP 连接。若 OPA 策略返回“重定向”或“修改上游地址”，此阶段会受影响。
- 响应处理（T6）： 响应缓存、压缩、访问日志写入。OPA 不直接参与，但日志中若包含 OPA 决策详情，会增加 I/O 延迟。
常见误区： 很多团队将 OPA 集成后的整体延迟上升全部归因于 OPA 评估慢。实际案例中，超过 40% 的延迟增量来自“插件链执行顺序不当”（如将 OPA 放在限流之前）或“上游连接池耗尽”（OPA 决策导致请求被拒绝后重试风暴）。诊断时必须逐阶段分解。
3.4 三种网关的请求生命周期差异
虽然通用模型一致，但具体实现细节会影响延迟分布与 OPA 集成方式：
| 生命周期阶段 | Kong 差异点 | Envoy 差异点 | APISIX 差异点 |
|---|---|---|---|
| 连接建立 | 依赖 Nginx Worker 模型，每个 Worker 独立监听 | 多线程 + 非阻塞，连接共享更高效 | 基于 OpenResty，但优化了 TLS 会话复用 |
| 路由匹配 | 基于 lua-resty-radixtree，支持动态路由 | 基于 Trie + 前缀树，匹配性能稳定 | 基于 radix tree + 缓存，支持 10 万级路由 |
| 插件链执行 | Lua 插件按优先级串行执行，OPA 插件需自行实现缓存 | Filter 链可并行（如多个 HTTP Filter），OPA 通过 External Authorization 异步调用 | Lua 插件 + Plugin Runner 支持多语言，OPA 插件内置缓存与批量查询 |
| 上游转发 | 使用 Nginx upstream，支持健康检查与重试 | 内置连接池与断路器，支持重试预算 | 支持一致性哈希与动态上游发现 |
OPA 集成最佳实践： 在 Envoy 中优先使用 External Authorization Filter（gRPC 协议），避免在 Filter 链中嵌入 Lua OPA 客户端导致 Worker 阻塞；在 Kong/APISIX 中，建议将 OPA 插件放在限流之后、日志之前，并开启 决策缓存（TTL 根据策略敏感度设置 1-30 秒）。