API 网关（Spring Cloud Gateway / Kong / APISIX）

API 网关概述

网关职责

API 网关是微服务架构的入口层，承担客户端与后端服务之间的中间层职责。核心功能包括：

职责	说明
路由转发	根据请求路径、Header、参数等条件将请求分发到对应后端服务
身份认证	统一校验 JWT、OAuth2、API Key，避免每个服务重复实现认证逻辑
限流熔断	防止突发流量冲垮后端，支持令牌桶、滑动窗口等算法
请求/响应过滤	修改请求头和响应头、请求体转换、添加公共参数
协议转换	将 HTTP 请求转为 gRPC、Dubbo 协议，或反向转换
日志与监控	统一采集请求日志、调用链追踪、指标上报（Prometheus / ELK）
灰度发布	按 Header、Cookie、权重等条件将流量导向不同版本的服务

网关 vs 负载均衡 vs 反向代理

组件	层次	核心能力	典型产品
反向代理	L4/L7	隐藏后端服务器、TLS 卸载、静态资源缓存	Nginx、HAProxy
负载均衡	L4/L7	按策略分发流量（轮询/最小连接/一致性哈希）	Nginx Upstream、LVS、F5
API 网关	L7	路由 + 认证 + 限流 + 熔断 + 协议转换 + 可观测性	Spring Cloud Gateway、Kong、APISIX

反向代理和负载均衡侧重流量调度和网络层的职责，API 网关在此基础上叠加了应用层的治理能力（认证、限流、熔断、服务发现集成等），是微服务架构的"前置大脑"。

Spring Cloud Gateway

Spring Cloud Gateway 基于 Spring WebFlux 构建，运行在 Netty 之上，采用响应式非阻塞 I/O 模型，是 Spring Cloud 生态中的官方网关组件。

WebFlux 非阻塞模型

传统 Servlet 容器（Tomcat）采用线程池模型——每个请求分配一个线程，线程在 I/O 操作时阻塞等待。WebFlux 基于 Reactor 响应式流规范，使用事件循环（Event Loop）机制，少量线程即可处理大量并发请求。

线程模型对比：

text

Servlet（Tomcat）:
  请求 → 线程池分配线程 → 线程阻塞等待 I/O → 释放线程
  线程数 ≈ 最大并发数，Context 切换开销大

WebFlux（Netty）:
  请求 → EventLoop 注册回调 → I/O 就绪时回调执行
  线程数 ≈ CPU 核心数 × 2，无阻塞等待

java

// WebFlux Controller 示例——返回 Mono/Flux 响应式类型
@RestController
public class GatewayController {

    @GetMapping("/hello")
    public Mono<String> hello() {
        return Mono.just("Hello from Gateway");
    }

    @GetMapping("/users/{id}")
    public Mono<User> getUser(@PathVariable Long id) {
        return webClient.get()
                .uri("http://user-service/users/{id}", id)
                .retrieve()
                .bodyToMono(User.class);
    }
}

核心架构：Route / Predicate / Filter

Spring Cloud Gateway 的三个核心概念：

Route（路由）：网关的基本构建块，包含 ID、目标 URI、Predicate 集合、Filter 集合。
Predicate（断言）：匹配请求的条件，满足条件则执行对应的路由规则。
Filter（过滤器）：对请求或响应进行修改的拦截器，分为 Pre 和 Post 两种执行阶段。

路由匹配流程：

text

客户端请求
    │
    ▼
Predicate 链 → 依次匹配 → 命中则选择该 Route
    │
    ▼
Pre Filter 链 → 修改请求（认证/鉴权/加头/参数校验）
    │
    ▼
转发到下游服务
    │
    ▼
Post Filter 链 → 修改响应（加头/缓存/日志）
    │
    ▼
返回给客户端

YAML 配置示例：

yaml

spring:
  cloud:
    gateway:
      routes:
        - id: user-service
          uri: lb://user-service          # 服务发现方式
          predicates:
            - Path=/api/user/**
          filters:
            - StripPrefix=1               # 去掉 /api 前缀
            - AddRequestHeader=X-Gateway, true
            - name: RequestRateLimiter
              args:
                redis-rate-limiter.replenishRate: 10
                redis-rate-limiter.burstCapacity: 20

        - id: order-service
          uri: http://192.168.1.100:8080   # 直连方式
          predicates:
            - Path=/api/order/**
            - Method=GET
          filters:
            - StripPrefix=1

内置 Predicate

Spring Cloud Gateway 提供了一系列开箱即用的断言工厂：

断言工厂	作用	示例
`Path`	按请求路径匹配	`Path=/api/user/,/api/order/`
`Header`	按请求头匹配	`Header=X-Request-Id, \d+`
`Query`	按查询参数匹配	`Query=foo, bar` 或 `Query=page`
`Method`	按 HTTP 方法匹配	`Method=GET,POST`
`Cookie`	按 Cookie 匹配	`Cookie=token, .*`
`Host`	按 Host 头匹配	`Host=**.example.com`
`RemoteAddr`	按客户端 IP 匹配	`RemoteAddr=192.168.1.0/24`
`Weight`	按权重分配灰度流量	`Weight=group1, 80`
`After/Before/Between`	按时间匹配	`After=2025-01-01T00:00:00+08:00[Asia/Shanghai]`

多 Predicate 组合（AND 关系）：

yaml

predicates:
  - Path=/api/order/**
  - Method=POST
  - Header=X-Version, v2
  - Query=userId, \d+

只有同时满足上述四个条件的请求才会转发到该路由。

自定义 Filter

GatewayFilter（针对特定路由）

java

@Component
public class AuthGatewayFilterFactory
        extends AbstractGatewayFilterFactory<AuthGatewayFilterFactory.Config> {

    public AuthGatewayFilterFactory() {
        super(Config.class);
    }

    @Override
    public GatewayFilter apply(Config config) {
        return (exchange, chain) -> {
            String token = exchange.getRequest().getHeaders()
                    .getFirst("Authorization");
            if (token == null || !token.startsWith("Bearer ")) {
                exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED);
                return exchange.getResponse().setComplete();
            }
            // 校验 token ...
            return chain.filter(exchange);
        };
    }

    @Data
    public static class Config {
        private List<String> whiteList;
    }
}

yaml

filters:
  - name: Auth
    args:
      whiteList:
        - /api/public/**
        - /api/login

GlobalFilter（全局生效）

java

@Component
@Order(-1)
public class RequestLogGlobalFilter implements GlobalFilter {

    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        ServerHttpRequest request = exchange.getRequest();
        log.info("[Gateway] {} {} - headers: {}",
                request.getMethod(),
                request.getURI(),
                request.getHeaders());

        long start = System.currentTimeMillis();
        return chain.filter(exchange).then(Mono.fromRunnable(() -> {
            long elapsed = System.currentTimeMillis() - start;
            log.info("[Gateway] {} {} - status: {} - {}ms",
                    request.getMethod(),
                    request.getURI(),
                    exchange.getResponse().getStatusCode(),
                    elapsed);
        }));
    }
}

熔断整合

整合 Sentinel

yaml

spring:
  cloud:
    gateway:
      routes:
        - id: sentinel-example
          uri: lb://order-service
          predicates:
            - Path=/api/order/**
          filters:
            - name: SentinelGatewayFilter
              args:
                fallbackUri: forward:/fallback

java

// 配置 Sentinel 网关流控规则
@PostConstruct
public void initGatewayRules() {
    Set<GatewayFlowRule> rules = new HashSet<>();
    rules.add(new GatewayFlowRule("order-service")
            .setResourceMode(SentinelGatewayConstants.RESOURCE_MODE_ROUTE_ID)
            .setCount(100)           // QPS 阈值
            .setIntervalSec(1));
    GatewayRuleManager.loadRules(rules);
}

整合 Resilience4j

yaml

spring:
  cloud:
    gateway:
      routes:
        - id: resilience4j-example
          uri: lb://order-service
          predicates:
            - Path=/api/order/**
          filters:
            - name: CircuitBreaker
              args:
                name: orderCircuitBreaker
                fallbackUri: forward:/fallback/order
                statusCodes:
                  - 500
                  - 503

yaml

# application.yml — Resilience4j 配置
resilience4j:
  circuitbreaker:
    instances:
      orderCircuitBreaker:
        registerHealthIndicator: true
        slidingWindowSize: 10
        minimumNumberOfCalls: 5
        failureRateThreshold: 50
        waitDurationInOpenState: 30s
        permittedNumberOfCallsInHalfOpenState: 3
        automaticTransitionFromOpenToHalfOpenEnabled: true
  timelimiter:
    instances:
      orderCircuitBreaker:
        timeoutDuration: 5s

限流（RequestRateLimiter）

Spring Cloud Gateway 基于 Redis +令牌桶算法 实现请求限流：

yaml

spring:
  cloud:
    gateway:
      routes:
        - id: rate-limit-route
          uri: lb://user-service
          predicates:
            - Path=/api/user/**
          filters:
            - name: RequestRateLimiter
              args:
                key-resolver: "#{@userKeyResolver}"
                redis-rate-limiter.replenishRate: 10   # 每秒填充令牌数
                redis-rate-limiter.burstCapacity: 20   # 令牌桶容量
                redis-rate-limiter.requestedTokens: 1  # 每次请求消耗令牌数

java

// 自定义限流 KeyResolver —— 按用户 ID 限流
@Bean
public KeyResolver userKeyResolver() {
    return exchange -> {
        String userId = exchange.getRequest().getHeaders()
                .getFirst("X-User-Id");
        if (userId == null) {
            return Mono.just("anonymous");
        }
        return Mono.just(userId);
    };
}

CORS 配置

yaml

spring:
  cloud:
    gateway:
      globalcors:
        cors-configurations:
          '[/**]':
            allowed-origins:
              - "https://admin.example.com"
              - "https://app.example.com"
            allowed-methods:
              - GET
              - POST
              - PUT
              - DELETE
            allowed-headers: "*"
            allow-credentials: true
          '[/api/public/**]':
            allowed-origins: "*"
            allowed-methods:
              - GET
            max-age: 3600

Kong

Kong 是基于 OpenResty（Nginx + LuaJIT）构建的高性能 API 网关，采用 Lua 编写核心逻辑，利用 Nginx 的事件驱动模型获得极高的吞吐能力。

架构原理

text

┌───────────────────────────────────────────┐
│                Kong 节点                    │
│  ┌─────────────────────────────────────┐   │
│  │        Nginx Worker 进程池           │   │
│  │  ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐  │   │
│  │  │ W-1 │ │ W-2 │ │ W-3 │ │ W-N │  │   │
│  │  └──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘  │   │
│  │     │        │        │        │       │
│  │  ┌──┴────────┴────────┴────────┴──┐   │
│  │  │     Lua VM（共享字典）          │   │
│  │  └───────────────────────────────┘   │
│  └─────────────────────────────────────┘   │
│        │                                    │
│        ▼                                    │
│  ┌──────────┐     ┌──────────┐              │
│  │ PostgreSQL│ 或 │  声明式   │  ← 配置来源  │
│  │  (DB 模式)│     │ YAML文件  │  (DB-less)  │
│  └──────────┘     └──────────┘              │
└───────────────────────────────────────────┘

核心组件：

OpenResty：将 Lua 脚本嵌入 Nginx 请求处理阶段（init / rewrite / access / header_filter / body_filter / log），实现插件机制。
数据库：支持 PostgreSQL（DB 模式）或声明式 YAML（DB-less 模式），存储路由、服务、插件配置。
Admin API：RESTful 管理接口，支持 CRUD 操作所有网关资源。

DB-less 模式

DB-less 模式无需数据库依赖，通过 YAML 声明式配置文件启动，适合 Kubernetes 等容器化部署。

yaml

# kong.yml — DB-less 声明式配置
_format_version: "3.0"
_transform: true

services:
  - name: user-service
    host: user-svc.internal
    port: 8080
    protocol: http
    routes:
      - name: user-route
        paths:
          - /api/user
        methods:
          - GET
          - POST
        strip_path: true
        plugins:
          - name: key-auth
            enabled: true
          - name: rate-limiting
            config:
              minute: 100
              policy: local

  - name: order-service
    host: order-svc.internal
    port: 8080
    protocol: http
    routes:
      - name: order-route
        paths:
          - /api/order
        methods:
          - GET
        strip_path: true

consumers:
  - username: app-client
    keyauth_credentials:
      - key: sk_test_abc123

Admin API

Kong 通过 RESTful 接口管理所有网关配置：

bash

# 添加 Service
curl -s -X POST http://localhost:8001/services \
  -H "Content-Type: application/json" \
  -d '{
    "name": "user-service",
    "host": "user-svc.internal",
    "port": 8080,
    "protocol": "http"
  }'

# 添加 Route
curl -s -X POST http://localhost:8001/services/user-service/routes \
  -H "Content-Type: application/json" \
  -d '{
    "name": "user-route",
    "paths": ["/api/user"],
    "methods": ["GET", "POST"],
    "strip_path": true
  }'

# 添加插件
curl -s -X POST http://localhost:8001/routes/user-route/plugins \
  -H "Content-Type: application/json" \
  -d '{
    "name": "rate-limiting",
    "config": {
      "minute": 100,
      "policy": "local"
    }
  }'

# 查询所有 Service
curl -s http://localhost:8001/services | jq .

# 查看节点状态
curl -s http://localhost:8001/status | jq .

Konga UI

Konga 是 Kong 的开源管理面板，提供 Web 界面进行可视化配置：

bash

# Docker 部署 Konga
docker run -d --name konga \
  -p 1337:1337 \
  -e "NODE_ENV=production" \
  -e "DB_ADAPTER=postgres" \
  -e "DB_URI=postgresql://kong:kong@kong-db:5432/konga" \
  pantsel/konga

Konga 支持的功能：Service / Route / Consumer / Plugin 的 CRUD 操作、Upstream 健康检查可视化、快照导入导出。

插件体系

Kong 的插件以 Lua 模块形式运行，可插入 Nginx 请求处理的各个阶段。

常用插件：

插件类别	插件名	功能
认证	`key-auth`	API Key 认证
认证	`jwt`	JWT 令牌校验
认证	`oauth2`	OAuth 2.0 授权码模式
认证	`basic-auth`	HTTP Basic 认证
限流	`rate-limiting`	基于计数器/滑动窗口的限流
限流	`response-ratelimiting`	按响应状态码限流
日志	`file-log`	将请求日志写入文件
日志	`http-log`	将请求日志发送到 HTTP 端点
日志	`syslog`	将请求日志发送到 Syslog
日志	`prometheus`	暴露 Prometheus 指标
请求转换	`request-transformer`	修改请求头、查询参数、请求体
响应转换	`response-transformer`	修改响应头、响应体
代理	`proxy-cache`	响应缓存
安全	`ip-restriction`	IP 白名单/黑名单
安全	`cors`	CORS 跨域配置
服务器无感知	`aws-lambda`	直接调用 AWS Lambda 函数

自定义 Lua 插件示例：

lua

-- custom-plugin/handler.lua
local CustomHandler = {
  VERSION  = "1.0.0",
  PRIORITY = 1000,
}

function CustomHandler:access(conf)
  local consumer = kong.client.get_consumer()
  if not consumer then
    return kong.response.exit(401, { message = "Authentication required" })
  end

  -- 注入自定义 Header
  kong.service.request.set_header("X-Custom-Plugin", conf.custom_header_value)
end

function CustomHandler:log(conf)
  -- 在日志阶段记录请求耗时
  local elapsed = ngx.now() - kong.request.get_start_time()
  kong.log.notice("request elapsed: ", elapsed)
end

return CustomHandler

Docker Compose 部署 Kong + PostgreSQL：

yaml

version: '3.8'
services:
  kong-db:
    image: postgres:14-alpine
    environment:
      POSTGRES_DB: kong
      POSTGRES_USER: kong
      POSTGRES_PASSWORD: kong

  kong-migrations:
    image: kong:3.7
    depends_on:
      - kong-db
    environment:
      KONG_DATABASE: postgres
      KONG_PG_HOST: kong-db
    command: kong migrations bootstrap

  kong:
    image: kong:3.7
    depends_on:
      kong-migrations:
        condition: service_completed_successfully
    ports:
      - "8000:8000"   # 代理端口
      - "8443:8443"   # HTTPS 代理端口
      - "8001:8001"   # Admin API
    environment:
      KONG_DATABASE: postgres
      KONG_PG_HOST: kong-db
      KONG_PROXY_ACCESS_LOG: /dev/stdout
      KONG_ADMIN_ACCESS_LOG: /dev/stdout
      KONG_PROXY_ERROR_LOG: /dev/stderr
      KONG_ADMIN_ERROR_LOG: /dev/stderr
      KONG_ADMIN_LISTEN: 0.0.0.0:8001

APISIX

Apache APISIX 是 Apache 软件基金会的顶级项目，基于 OpenResty + etcd 构建，以高性能和动态热加载为核心理念。

架构原理

text

┌─────────────────────────────────────────────────────┐
│                    APISIX 节点                        │
│  ┌─────────────────────────────────────────────┐    │
│  │            Nginx Worker 进程                  │    │
│  │  ┌─────┐ ┌─────┐ ┌─────┐                   │    │
│  │  │ W-1 │ │ W-2 │ │ W-N │  ← 共享内存缓存   │    │
│  │  └──┬──┘ └──┬──┘ └──┬──┘  路由/插件配置     │    │
│  │     │        │        │                      │    │
│  │  ┌──┴────────┴────────┴──┐                   │    │
│  │  │     Lua VM 共享字典    │                   │    │
│  │  └───────────────────────┘                   │    │
│  └─────────────────────────────────────────────┘    │
│          │    ▲                                     │
│          ▼    │  watch / sync                       │
│  ┌──────────────────┐                               │
│  │  etcd 集群       │  ← 配置中心（强一致、高可用）  │
│  │  (RAFT 共识算法)  │                               │
│  └──────────────────┘                               │
│          │                                           │
│          ▼                                           │
│  ┌──────────────────┐                               │
│  │ Admin API : 9180 │  ← RESTful 管理接口           │
│  └──────────────────┘                               │
│          │                                           │
│          ▼                                           │
│  ┌──────────────────┐                               │
│  │ APISIX Dashboard │  ← Web 管理界面               │
│  └──────────────────┘                               │
└─────────────────────────────────────────────────────┘

核心特点：

etcd 作为配置中心：替代 Kong 的 PostgreSQL，使用 RAFT 协议保证配置强一致性，支持配置变更的实时 Watch 推送。
插件热加载：修改路由插件后无需 reload，配置秒级生效。
多语言插件支持：除了 Lua，还支持 Java（JAR）、Wasm、Python、Go 编写插件。

插件热加载机制

APISIX 的配置存储在 etcd 中，Worker 进程通过定时轮询 + Watch 机制感知变化，将最新配置加载到共享内存。整个过程零停机。

bash

# 路由变更 —— 立即生效，无需 reload
curl -s -X PUT http://127.0.0.1:9180/apisix/admin/routes/1 \
  -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" \
  -H "Content-Type: application/json" \
  -d '{
    "uri": "/api/user/*",
    "upstream": {
      "type": "roundrobin",
      "nodes": {
        "10.0.0.1:8080": 1,
        "10.0.0.2:8080": 1
      }
    },
    "plugins": {
      "limit-count": {
        "count": 100,
        "time_window": 60,
        "rejected_code": 429
      },
      "key-auth": {}
    }
  }'

Admin API 与 Dashboard

Admin API：

bash

# 创建 Upstream
curl -s -X PUT http://127.0.0.1:9180/apisix/admin/upstreams/user-upstream \
  -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" \
  -d '{
    "type": "roundrobin",
    "nodes": {
      "user-service:8080": 1
    },
    "checks": {
      "active": {
        "type": "http",
        "http_path": "/health",
        "interval": 10,
        "healthy": {"successes": 2},
        "unhealthy": {"failures": 3, "http_fails": 3}
      }
    }
  }'

# 创建 Route（关联 Upstream）
curl -s -X PUT http://127.0.0.1:9180/apisix/admin/routes/user-route \
  -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" \
  -d '{
    "uri": "/api/user/*",
    "methods": ["GET", "POST"],
    "upstream_id": "user-upstream",
    "plugins": {
      "prometheus": {},
      "cors": {},
      "limit-req": {
        "rate": 10,
        "burst": 20,
        "rejected_code": 429
      }
    }
  }'

# 创建 Consumer & 授权
curl -s -X PUT http://127.0.0.1:9180/apisix/admin/consumers/app-client \
  -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" \
  -d '{
    "username": "app-client",
    "plugins": {
      "key-auth": {
        "key": "sk_test_abc123"
      }
    }
  }'

# 查询路由列表
curl -s http://127.0.0.1:9180/apisix/admin/routes \
  -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1"

Docker Compose 部署：

yaml

version: '3.8'
services:
  etcd:
    image: bitnami/etcd:3.5
    environment:
      ALLOW_NONE_AUTHENTICATION: "yes"
      ETCD_ADVERTISE_CLIENT_URLS: "http://0.0.0.0:2379"

  apisix:
    image: apache/apisix:3.9
    depends_on:
      - etcd
    ports:
      - "9080:9080"   # HTTP 代理端口
      - "9180:9180"   # Admin API
    volumes:
      - ./apisix_conf/config.yaml:/usr/local/apisix/conf/config.yaml:ro

  apisix-dashboard:
    image: apache/apisix-dashboard:3.0
    depends_on:
      - apisix
    ports:
      - "9000:9000"
    environment:
      - APISIX_HOST=http://apisix:9180

Dashboard 功能：

APISIX Dashboard 提供 Web GUI 管理网关配置，支持：

路由（Route）的 CRUD 与调试
Upstream 健康检查状态可视化
消费者（Consumer）/ 凭证管理
插件可视化配置
流量指标（集成 Prometheus + Grafana）
发布历史与版本回滚

常用插件

插件类别	插件名	功能
认证	`key-auth`	API Key 认证
认证	`jwt-auth`	JWT 认证
认证	`basic-auth`	Basic 认证
认证	`hmac-auth`	HMAC 签名认证
限流	`limit-req`	基于漏桶算法的请求限流
限流	`limit-count`	固定窗口计数器限流
限流	`limit-conn`	并发连接数限制
日志	`syslog`	Syslog 日志
日志	`kafka-logger`	发送日志到 Kafka
日志	`http-logger`	发送日志到 HTTP 端点
日志	`skywalking-logger`	集成 Apache SkyWalking
安全	`cors`	跨域配置
安全	`ip-restriction`	IP 黑白名单
安全	`referer-restriction`	Referer 校验
流量控制	`proxy-rewrite`	重写 URI / Host / Headers
流量控制	`redirect`	URL 重定向
可观测性	`prometheus`	暴露 Prometheus 指标
可观测性	`zipkin`	Zipkin 链路追踪

与 Kong 对比

维度	APISIX	Kong
配置存储	etcd（强一致、Watch 机制）	PostgreSQL（DB 模式）/ YAML（DB-less）
配置生效	热加载，秒级生效	DB 模式需 Admin API 同步；DB-less 需 reload
插件语言	Lua + Java + Wasm + Go + Python	Lua
控制面	Admin API + Dashboard	Admin API + Konga（社区）
社区归属	Apache 顶级项目	Kong Inc. 商业公司主导
性能（官方基准）	约 140K QPS（单核）	约 50K QPS（单核）
路由匹配	支持 radixtree（高性能前缀树）	正则 + 优先级排序
K8s 集成	Ingress Controller 成熟度高	Kong Ingress Controller
管理 UI	Dashboard 官方维护	Konga 社区维护

网关对比表

维度	Spring Cloud Gateway	Kong	APISIX
架构	WebFlux + Netty（Java）	OpenResty + Nginx（Lua）	OpenResty + Nginx（Lua）
核心语言	Java	Lua	Lua（支持多语言插件）
配置存储	配置文件 / Nacos / Consul	PostgreSQL / YAML	etcd
性能	★★★（非阻塞，吞吐较高）	★★★★（Nginx 内核）	★★★★★（前缀树路由、共享内存优化）
动态路由	需配合配置中心实现热更新	DB 模式动态；DB-less 需 reload	原生支持，etcd Watch 热加载
插件丰富度	★★（需 Java 编码）	★★★★（60+ 官方插件）	★★★★★（100+ 插件 + 多语言）
学习成本	★★★（需 Spring 生态基础）	★★（YAML + API 快速上手）	★★（API 风格类似）
运维复杂度	★★（Java 进程，常规运维）	★★★（需管理 PostgreSQL）	★★（etcd 集群需维护）
生态集成	Spring Cloud 原生集成	平台无关，集成广泛	K8s Ingress 生态、云原生
可观测性	Actuator + Micrometer + Sleuth	Prometheus + OpenTelemetry	Prometheus + SkyWalking + Zipkin
商用支持	VMware 生态社区	Kong Inc.（Kong Enterprise）	API7.ai（商业支持）
开源协议	Apache 2.0	Apache 2.0	Apache 2.0

性能测试参考（非严格定量）

text

场景：单机 4C8G，100 并发，1KB 响应，简单路由转发

Spring Cloud Gateway: ~20K - 35K QPS
Kong:               ~30K - 60K QPS
APISIX:             ~60K - 140K QPS

实际性能受插件数量、路由数量、硬件配置影响较大，以上仅作参考。网关的性能瓶颈通常在后端服务响应时间，而非网关本身。

选型建议

Java 技术栈 → Spring Cloud Gateway

推荐场景：

团队以 Java / Spring Boot 为主的技术栈
系统中已深度使用 Spring Cloud（Nacos、Sentinel、Seata）生态
网关需要与 Spring Cloud 微服务框架紧密集成（服务发现、配置中心）
定制需求较多，需要通过 Java 编写自定义 Filter / Predicate
不希望引入额外的运维组件（PostgreSQL / etcd）

注意事项：

非 Spring 技术栈的服务集成需要额外配置
插件生态不如 Kong / APISIX 丰富，复杂功能需要自行编码
动态路由能力依赖配置中心（如 Nacos），非开箱即用
性能在极高并发场景下不如 Nginx 内核的网关

Kubernetes 架构 → APISIX

推荐场景：

基于 Kubernetes 的云原生架构
需要高性能 API 网关 + Ingress Controller
流量治理需求复杂（灰度发布、蓝绿部署、多协议支持）
需要配置热加载、零停机更新
团队偏向云原生，能维护 etcd 集群

推荐理由：

APISIX Ingress Controller 成熟度高，声明式配置天然适配 K8s 资源模型
etcd 本身就是 K8s 的配置存储，运维经验可复用
插件热加载，路由变更即时生效，适合频繁发布场景
社区活跃，Apache 顶级项目背书

混合 / 平台级 → Kong

推荐场景：

多语言技术栈（Java + Go + Node.js + Python）并存
需要成熟的管理面板（Konga / Kong Manager）
企业级功能需求（开发者门户、API 版本管理、API Key 工作流）
已在使用，或需要商业支持（Kong Enterprise）

推荐理由：

插件生态系统成熟，官方维护 60+ 插件覆盖大部分场景
多层架构清晰，适合 API 管理平台化
商业版本提供企业级功能（RBAC、审计日志、开发者门户）
文档完善，社区成熟，国内外实践案例丰富

选型决策树

text

技术栈是 Java / Spring Cloud 为主？
├── 是 → Spring Cloud Gateway
└── 否
    ├── 部署在 Kubernetes？
    │   ├── 是 → APISIX（Ingress Controller）
    │   └── 否
    │       ├── 需要企业级功能 / 商业支持？
    │       │   ├── 是 → Kong Enterprise
    │       │   └── 否
    │       │       ├── 追求极限性能 + 热加载？
    │       │       │   ├── 是 → APISIX
    │       │       │   └── 否 → Kong
    │       └── ...
    └── ...

API 网关（Spring Cloud Gateway / Kong / APISIX） ​

API 网关概述 ​

网关职责 ​

网关 vs 负载均衡 vs 反向代理 ​

Spring Cloud Gateway ​

WebFlux 非阻塞模型 ​

核心架构：Route / Predicate / Filter ​

内置 Predicate ​

自定义 Filter ​

GatewayFilter（针对特定路由） ​

GlobalFilter（全局生效） ​

熔断整合 ​

整合 Sentinel ​

整合 Resilience4j ​

限流（RequestRateLimiter） ​

CORS 配置 ​

Kong ​

架构原理 ​

DB-less 模式 ​

Admin API ​

Konga UI ​

插件体系 ​

APISIX ​

架构原理 ​

插件热加载机制 ​

Admin API 与 Dashboard ​

常用插件 ​

与 Kong 对比 ​

网关对比表 ​

性能测试参考（非严格定量） ​

选型建议 ​

Java 技术栈 → Spring Cloud Gateway ​

Kubernetes 架构 → APISIX ​

混合 / 平台级 → Kong ​

选型决策树 ​

API 网关（Spring Cloud Gateway / Kong / APISIX）

API 网关概述

网关职责

网关 vs 负载均衡 vs 反向代理

Spring Cloud Gateway

WebFlux 非阻塞模型

核心架构：Route / Predicate / Filter

内置 Predicate

自定义 Filter

GatewayFilter（针对特定路由）

GlobalFilter（全局生效）

熔断整合

整合 Sentinel

整合 Resilience4j

限流（RequestRateLimiter）

CORS 配置

Kong

架构原理

DB-less 模式

Admin API

Konga UI

插件体系

APISIX

架构原理

插件热加载机制

Admin API 与 Dashboard

常用插件

与 Kong 对比

网关对比表

性能测试参考（非严格定量）

选型建议

Java 技术栈 → Spring Cloud Gateway

Kubernetes 架构 → APISIX

混合 / 平台级 → Kong

选型决策树