1. API 网关基础：定义、核心功能与架构位置
API 网关是微服务架构中所有客户端请求的单一入口点，负责将外部请求路由到内部微服务，并在这一过程中集中执行横切关注点（如认证、限流、监控）。在分布式系统中，API 网关不仅是流量调度器，更是系统安全与治理的第一道防线。
1.1 API 网关定义
API 网关是一个位于客户端与后端微服务之间的中间层服务，它封装了内部系统的架构细节，为客户端提供统一的 API 接口。客户端无需知道每个微服务的具体地址，只需与网关通信，由网关完成请求转发、协议转换和结果聚合。
核心价值：解耦客户端与后端服务，降低系统复杂度，提升安全性与可观测性。
1.2 核心功能矩阵
API 网关的核心功能可归纳为三大类：路由、限流与认证。下表列出了每类功能的具体职责与典型实现机制：
| 功能类别 | 具体职责 | 典型实现机制 | 延迟影响 |
|---|---|---|---|
| 路由 | 根据请求路径、Header、参数将请求转发至对应微服务 | 路由表匹配、负载均衡、服务发现 | 低（毫秒级匹配） |
| 限流 | 控制单位时间内的请求量，防止系统过载 | 令牌桶、漏桶、滑动窗口 | 中（需计数与判断） |
| 认证 | 验证请求者身份，确保合法访问 | JWT 校验、OAuth2、 | 中高（需解密与远程校验） |
| 协议转换 | 将外部 HTTP 请求转换为内部 RPC/gRPC 协议 | 协议适配器、序列化/反序列化 | 中（需编解码） |
| 监控与日志 | 记录请求指标、错误日志、调用链追踪 | Prometheus 指标、ELK 日志、OpenTelemetry | 低（异步上报） |
调优视角：在延迟诊断中，路由匹配通常是性能瓶颈最小的环节；限流与认证的缓存策略、协议转换的序列化效率才是关键优化点。
1.3 在微服务架构中的位置
API 网关位于客户端与微服务集群之间，是南北向流量的统一入口。下图展示了 API 网关在典型微服务架构中的位置与交互关系：
1.4 网关在请求链路中的角色
从一次完整的请求生命周期来看，API 网关处于以下关键位置：
- 入口拦截：接收客户端 HTTP/HTTPS 请求，进行 TLS 终止与协议解析。
- 认证校验：解析 JWT 或校验 ，确认请求合法性。
- 限流判断：根据用户/接口维度检查是否超出速率限制。
- 路由转发：匹配路由规则，将请求转发至目标微服务实例。
- 响应聚合：可选地聚合多个微服务响应，返回给客户端。
延迟陷阱：网关若在认证环节引入远程调用（如每次请求都查询用户中心），将显著增加 P99 延迟。建议使用本地缓存 + 定期刷新策略，将认证延迟控制在 1ms 以内。
1.5 常见网关选型对比
不同 API 网关在性能、功能与生态上存在差异，下表对比了三种主流网关：
| 网关 | 语言 | 性能（QPS） | 核心优势 | 适用场景 |
|---|---|---|---|---|
| Kong | Lua / OpenResty | 高（~50k） | 插件生态丰富，社区活跃 | 企业级 API 管理 |
| APISIX | Lua / Go | 极高（~100k） | 热更新、低延迟、多语言插件 | 高性能微服务场景 |
| Spring Cloud Gateway | Java / Reactor | 中（~20k） | 与 Spring 生态无缝集成 | Java 技术栈团队 |
选型建议：若团队以 Java 为主且已有 Spring Cloud 基础设施，优先选择 Spring Cloud Gateway；若追求极致性能与多协议支持，APISIX 或 Kong 是更优选择。
1.6 网关延迟的关键影响因素
在后续章节的延迟诊断中，以下因素将反复出现，提前建立认知有助于理解调优方向：
- 路由表大小：路由规则数量越多，匹配耗时线性增长。
- 认证缓存命中率：缓存未命中时需回源校验，延迟增加 5-20ms。
- 限流算法精度：滑动窗口比令牌桶更精确，但计算开销更高。
- 协议转换开销：JSON ↔ Protobuf 转换在大量请求下会显著消耗 CPU。
- 连接池管理：与后端服务的连接复用率直接影响转发延迟。