API网关选型与部署实战：Kong与APISIX路由配置对比

API网关是微服务架构的统一入口，承担路由转发、认证鉴权、限流熔断和协议转换职责。Kong和APISIX是当前最主流的两个开源API网关，均基于Nginx/OpenResty，但在架构设计、插件生态和性能特征上存在差异。本文从功能对比、部署配置到路由管理，给出API网关选型与落地的实战方案。

Kong与APISIX架构对比

Kong由Mashape于2015年开源，基于OpenResty构建，采用插件式架构。核心功能通过插件扩展，内置约80+插件覆盖认证、安全、流量控制和可观测性。Kong的配置存储在PostgreSQL或Cassandra中，通过Admin API管理路由和插件配置。Kong 3.x引入了数据平面插件开发支持，允许使用Go、JavaScript和Python编写自定义插件。

APISIX由Apache软件基金会孵化，同样基于OpenResty，但配置存储在etcd中而非关系型数据库。这意味着APISIX的配置变更通过etcd watch机制实时推送到所有网关节点，毫秒级生效，而Kong需要依赖数据库轮询或事件通知。APISIX原生支持动态路由、灰度发布和流量镜像，插件数量约100+，且插件热加载无需重启。

性能方面，两者在单核QPS上处于同一量级（5-10万QPS），APISIX在路由匹配上使用了Radix Tree算法，在路由数量超过1000条时匹配效率优于Kong的线性查找。Kong的优势在于成熟的商业生态（Kong Enterprise）和更广泛的社区文档。

Kong网关部署与路由配置

# docker-compose.yml
version: '3.8'
services:
  kong-database:
    image: postgres:15
    environment:
      POSTGRES_USER: kong
      POSTGRES_DB: kong
      POSTGRES_PASSWORD: kongpass
    volumes:
      - kong-db:/var/lib/postgresql/data

  kong:
    image: kong:3.4
    depends_on: [kong-database]
    environment:
      KONG_DATABASE: postgres
      KONG_PG_HOST: kong-database
      KONG_PG_USER: kong
      KONG_PG_PASSWORD: kongpass
      KONG_PROXY_LISTEN: 0.0.0.0:8000, 0.0.0.0:8443 ssl
      KONG_ADMIN_LISTEN: 0.0.0.0:8001
    ports:
      - "8000:8000"
      - "8443:8443"
      - "8001:8001"

volumes:
  kong-db:

Kong的配置模型为Service → Route → Plugin三层结构。Service定义上游服务地址，Route定义匹配规则，Plugin附加功能：

# 创建Service
curl -X POST http://localhost:8001/services   -H "Content-Type: application/json"   -d '{"name": "user-service", "url": "http://user-service:8080"}'

# 创建Route
curl -X POST http://localhost:8001/services/user-service/routes   -H "Content-Type: application/json"   -d '{
    "name": "user-api",
    "paths": ["/api/users"],
    "methods": ["GET", "POST", "PUT", "DELETE"],
    "strip_path": true
  }'

# 添加JWT认证插件
curl -X POST http://localhost:8001/routes/user-api/plugins   -d '{"name": "jwt", "config": {"run_on_preflight": true}}'

# 添加限流插件
curl -X POST http://localhost:8001/routes/user-api/plugins   -d '{
    "name": "rate-limiting",
    "config": {
      "minute": 100,
      "policy": "redis",
      "redis_host": "redis",
      "redis_port": 6379
    }
  }'

APISIX网关部署与路由配置

# docker-compose.yml
version: '3.8'
services:
  apisix-etcd:
    image: bitnami/etcd:3.5
    environment:
      ALLOW_NONE_AUTHENTICATION: "yes"
      ETCD_ADVERTISE_CLIENT_URLS: http://apisix-etcd:2379
    volumes:
      - etcd-data:/bitnami/etcd

  apisix:
    image: apache/apisix:3.8
    depends_on: [apisix-etcd]
    volumes:
      - ./apisix-config.yaml:/usr/local/apisix/conf/config.yaml
    ports:
      - "9080:9080"
      - "9443:9443"

volumes:
  etcd-data:

APISIX的配置模型为Route → Upstream → Plugin Consumer。Route直接定义路由和上游，结构更扁平：

curl -X POST http://localhost:9180/apisix/admin/routes/user-api   -H "X-API-KEY: your-admin-key"   -d '{
    "uri": "/api/users/*",
    "methods": ["GET", "POST", "PUT", "DELETE"],
    "upstream": {
      "type": "roundrobin",
      "nodes": {
        "user-service-v1:8080": 80,
        "user-service-v2:8080": 20
      },
      "checks": {
        "active": {
          "type": "http",
          "http_path": "/health",
          "healthy": {"interval": 5, "successes": 2},
          "unhealthy": {"interval": 5, "http_failures": 3}
        }
      }
    },
    "plugins": {
      "jwt-auth": {},
      "limit-count": {
        "count": 100,
        "time_window": 60,
        "rejected_code": 429,
        "policy": "redis-cluster"
      },
      "prometheus": {}
    }
  }'

APISIX的upstream支持权重分配，上面的配置将80%流量路由到v1，20%到v2，实现灰度发布。健康检查配置在upstream级别，自动剔除不健康的节点。

认证鉴权方案对比

Kong和APISIX都支持多种认证方式：JWT、OAuth2、API Key、LDAP、Basic Auth。在微服务场景中，JWT是最常用的方案：

# Kong JWT: 先创建Consumer，再添加JWT凭证
curl -X POST http://localhost:8001/consumers -d '{"username":"app-client"}'
curl -X POST http://localhost:8001/consumers/app-client/jwt   -d '{"algorithm":"HS256","key":"user-service-key","secret":"your-secret"}'

# 客户端请求时携带JWT
curl http://localhost:8000/api/users   -H "Authorization: Bearer eyJhbGci..."

# APISIX JWT: 在Consumer中直接配置jwt-auth插件
curl -X POST http://localhost:9180/apisix/admin/consumers   -H "X-API-KEY: your-admin-key"   -d '{
    "username": "app-client",
    "plugins": {
      "jwt-auth": {
        "key": "user-service-key",
        "algorithm": "HS256",
        "secret": "your-secret-key"
      }
    }
  }'

灰度发布与流量控制

APISIX的灰度发布通过upstream权重直接配置，也可以基于请求头条件路由：

# APISIX基于请求头的灰度
curl -X POST http://localhost:9180/apisix/admin/routes/user-api-v2   -H "X-API-KEY: your-admin-key"   -d '{
    "uri": "/api/users/*",
    "vars": [["http_x-version", "==", "v2"]],
    "upstream": {
      "type": "roundrobin",
      "nodes": {"user-service-v2:8080": 1}
    }
  }'

# 默认路由处理v1流量
curl -X POST http://localhost:9180/apisix/admin/routes/user-api-default   -H "X-API-KEY: your-admin-key"   -d '{
    "uri": "/api/users/*",
    "upstream": {
      "type": "roundrobin",
      "nodes": {"user-service-v1:8080": 1}
    }
  }'

APISIX的vars语法支持基于请求头、URL参数、客户端IP等条件进行路由分流，实现精细化的灰度策略。Kong通过Request Transformer和Traffic Control插件组合实现类似功能，配置链路更长。

可观测性与监控集成

# Kong启用Prometheus
curl -X POST http://localhost:8001/plugins   -d '{"name":"prometheus","config":{"status_code":true,"latency":true}}'

# Prometheus配置
scrape_configs:
  - job_name: 'kong'
    metrics_path: /metrics
    static_configs:
      - targets: ['kong:8001']

# APISIX启用Prometheus - 在路由配置中添加
"plugins": {
  "prometheus": {"prefer_name": true}
}
# 指标端点: :9091/apisix/prometheus/metrics

两者的指标维度基本一致：请求总数、状态码分布、上游延迟、网关处理延迟。APISIX的指标粒度更细，可以按路由名称和消费者名称分组统计。Kong的指标按Service和Route分组，在大量路由场景下标签基数较高，需要注意Prometheus的内存占用。

选型建议：路由数量在500条以下且团队对PostgreSQL运维熟悉，Kong是成熟稳定的选择；路由规模大、需要毫秒级配置生效、或需要基于条件的动态路由，APISIX在架构上更适合。两者的插件生态覆盖率相当，迁移成本主要在配置模型和Admin API的差异上。