2. 云原生网关基础：架构演进与主流选型对比
在深入 Rate Limit 版本差异校验 之前，必须先理解网关在云原生架构中的位置与形态。网关的演进本质上是流量治理能力从应用层剥离、下沉至基础设施层的过程。本章梳理架构演进脉络，并对主流网关进行技术选型对比。
2.1 网关架构演进：单体 → 微服务 → 服务网格
网关架构的演进与后端架构的复杂度强相关，经历了三个核心阶段：
核心洞察： 每一次架构演进，都是将“非业务功能”（认证、限流、熔断、观测）从业务代码中进一步剥离，向更底层、更透明的方向移动。
阶段一：单体架构下的网关（负载均衡器）
- 形态： Nginx / HAProxy 作为反向代理，负责 SSL 终结、静态资源分发、简单路由。
- 限流实现： 依赖 Nginx 的
limit_req/limit_conn模块，基于 IP 或 URL 做静态配置。 - 痛点： 配置变更需 reload，无法动态感知后端健康状态，限流规则与业务耦合在配置文件中。
阶段二：微服务架构下的网关（API Gateway）
- 形态： 独立部署的 API 网关层，如 Kong、APISIX、Spring Cloud Gateway。
- 核心能力： 动态路由、服务发现集成、认证授权、请求/响应转换、聚合限流、熔断降级。
- 限流演进： 支持分布式限流（Redis + 滑动窗口/令牌桶），限流策略可通过 Admin API 动态下发。
- 痛点： 网关层成为新的瓶颈点；业务代码仍需侵入式引入服务发现 SDK；限流规则版本管理混乱。
阶段三：服务网格架构下的网关（Ingress Gateway + Sidecar）
- 形态： 数据面由 Sidecar（Envoy）代理所有进出流量，控制面统一管理路由与安全策略。
- 网关角色： Ingress Gateway 作为集群入口，Sidecar 负责东西向流量治理。
- 限流演进： 限流策略通过 CRD（如
RateLimitConfig）声明式下发，Envoy 原生支持全局限流（Rate Limit Service + gRPC 协议）。 - 优势： 业务代码零侵入，限流规则版本可审计、可回滚，与 Istio/Envoy 控制面深度集成。
2.2 主流网关选型对比
当前生产环境最活跃的四款云原生网关：Kong、APISIX、Envoy、Spring Cloud Gateway。以下从架构、性能、限流机制、版本管理四个维度进行对比。
| 对比维度 | Kong | APISIX | Envoy | Spring Cloud Gateway |
|---|---|---|---|---|
| 核心语言 | Lua (OpenResty) | Lua + 多语言插件 | C++ | Java (Reactor) |
| 架构模型 | 控制面 + 数据面 (DB 驱动) | 控制面 + 数据面 (etcd 驱动) | 数据面 (xDS 控制面) | 嵌入应用 / 独立部署 |
| 动态配置 | 支持 (DB 轮询) | 支持 (etcd watch) | 支持 (xDS 热更新) | 支持 (Actuator + 配置中心) |
| 限流算法 | 令牌桶 + 滑动窗口 | 令牌桶 + 滑动窗口 + 计数器 | 令牌桶 + 全局限流 (gRPC) | 令牌桶 + 局部限流 (Redis) |
| 分布式限流 | Redis 集群 | Redis 集群 + etcd | Rate Limit Service (gRPC) | Redis + Spring Session |
| 限流版本管理 | DB 记录 + 标签 | etcd 版本 + 路由级快照 | 控制面 CRD 版本 (GitOps) | 配置中心版本 (Nacos/Apollo) |
| 性能 (QPS) | ~50k (单核) | ~70k (单核) | ~100k+ (单核) | ~20k (单核) |
| 社区生态 | 成熟 (企业版 + 插件市场) | 活跃 (Apache 孵化) | CNCF 毕业 (Istio 默认) | Spring 生态 (Java 首选) |
选型建议：
- Java 技术栈、中小规模： Spring Cloud Gateway + Nacos 配置中心，限流版本通过配置中心灰度发布。
- 高性能、多协议、服务网格： Envoy + Istio，限流版本通过 CRD 声明式管理，天然支持 GitOps 回滚。
- 动态路由、插件丰富、非 Java 团队： APISIX 或 Kong，限流版本需额外设计 Admin API 快照机制。
2.3 限流版本差异校验的架构位置
无论选择哪种网关，Rate Limit 版本差异校验 都发生在以下关键节点：
- 配置下发通道： 控制面 → 数据面（或配置中心 → 网关实例）的限流规则变更。
- 规则生效前： 新版本限流规则与当前运行版本进行差异比对（字段级 diff）。
- 回滚决策点： 当差异校验发现破坏性变更（如限流阈值归零、算法切换、scope 丢失）时，触发自动回滚护栏。
版本差异校验的常见陷阱：
- 算法切换未兼容： 从“令牌桶”切换为“滑动窗口”时，存量 未清空导致突发流量。
- scope 丢失： 新版本限流规则未包含
consumer或route维度，导致全局限流失效。 - 阈值归零： 配置中心误下发
rate: 0，网关直接拒绝所有请求。 - 版本号冲突： 多控制面同时下发不同版本，数据面无版本冲突检测机制。
本章为后续 Rate Limit 版本差异校验 的实战内容奠定了架构基础。理解网关演进脉络和选型差异，有助于在具体实现中针对不同网关的限流版本管理机制，设计差异化的校验与回滚策略。