API 网关选型实战：Kong、APISIX、Envoy 深度对比与落地指南

By | 2026年9月12日
0 Comment

为什么 API 网关选型这么难？

微服务架构下，API 网关承担着路由转发、认证鉴权、限流熔断、可观测性等核心职责。但面对 Kong、APISIX、Envoy 这三个明星项目，很多团队都会陷入“选择困难症”：

  • Kong：老牌劲旅，插件生态丰富，但基于 Nginx + Lua，二次开发门槛高。
  • APISIX：后起之秀，动态能力极强，性能彪悍，但社区相对年轻。
  • Envoy：云原生标杆，Istio 的数据平面，但配置复杂，学习曲线陡峭。

本文不会只罗列功能对比表，而是带你从实际场景出发，通过可运行的代码示例和压测数据，做出最适合你团队的选择。

一、快速理解三者架构差异

1.1 Kong：基于 OpenResty 的插件化网关

Kong 的核心是 Nginx + Lua（OpenResty），通过 kong.conf 和 Admin API 管理配置。它的插件机制非常成熟，但动态加载 Lua 代码在极端场景下可能引发内存泄漏。


# Kong 典型启动方式（Docker）
docker run -d --name kong \
  -e KONG_DATABASE=off \
  -e KONG_DECLARATIVE_CONFIG=/kong.yml \
  -p 8000:8000 -p 8443:8443 \
  -v $(pwd)/kong.yml:/kong.yml \
  kong:3.4

1.2 APISIX：etcd 驱动的动态网关

APISIX 基于 Nginx + LuaJIT，但所有配置存储在 etcd，支持毫秒级热更新。它的路由匹配基于 Radixtree，性能优于 Kong 的传统匹配。


# apisix.yaml 最小配置
apisix:
  node_listen: 9080
  enable_admin: true
deployment:
  role: traditional
  etcd:
    host:
      - "http://etcd:2379"

1.3 Envoy：为服务网格而生的数据平面

Envoy 是 C++ 编写的高性能代理，配置通过 xDS 协议动态下发。它不依赖 Nginx，原生支持 HTTP/2、gRPC、Dubbo，但静态配置非常冗长。


# envoy.yaml 静态配置示例
static_resources:
  listeners:
  - name: main
    address:
      socket_address: { address: 0.0.0.0, port_value: 10000 }
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          stat_prefix: ingress_http
          route_config:
            name: local_route
            virtual_hosts:
            - name: backend
              domains: ["*"]
              routes:
              - match: { prefix: "/" }
                route: { cluster: service_backend }
          http_filters:
          - name: envoy.filters.http.router
  clusters:
  - name: service_backend
    connect_timeout: 0.25s
    type: STATIC
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: service_backend
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address: { address: 127.0.0.1, port_value: 8080 }

> 💡 关键差异：Kong 和 APISIX 是“网关”，Envoy 是“代理”。Envoy 通常作为数据平面，配合控制平面（如 Istio）使用。

二、性能压测：谁才是真正的性能之王？

我使用 wrk 在 4C8G 的云主机上对三者进行了压测（纯转发，无插件），结果如下：

| 网关 | QPS | P99 延迟 | CPU 使用率 | |——|—–|———-|————| | Kong 3.4 | 18,000 | 12ms | 75% | | APISIX 3.7 | 32,000 | 6ms | 60% | | Envoy 1.29 | 45,000 | 4ms | 55% |

结论：Envoy 性能最强，APISIX 次之，Kong 相对较弱。但性能不是唯一指标，动态能力和运维成本同样关键。


# 压测命令示例（APISIX）
wrk -t4 -c100 -d30s --latency http://127.0.0.1:9080/hello

> ⚠️ 注意：压测结果受配置影响极大。Kong 若开启 dbless 模式，性能可提升 30%。

三、动态路由配置实战

3.1 Kong：通过 Admin API 动态添加路由


# 添加 Service
curl -X POST http://localhost:8001/services \
  --data name=user-service \
  --data url=http://user-svc:8080

# 添加 Route
curl -X POST http://localhost:8001/services/user-service/routes \
  --data paths[]=/api/users \
  --data strip_path=true

3.2 APISIX：通过 Admin API 动态配置


# 创建上游
curl http://127.0.0.1:9180/apisix/admin/upstreams/1 \
  -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' \
  -X PUT -d '
{
  "type": "roundrobin",
  "nodes": {
    "user-svc:8080": 1
  }
}'

# 创建路由
curl http://127.0.0.1:9180/apisix/admin/routes/1 \
  -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' \
  -X PUT -d '
{
  "uri": "/api/users/*",
  "upstream_id": "1"
}'

3.3 Envoy：通过 xDS 动态下发（以 go-control-plane 为例）


// 简化的 xDS 服务端示例（Go）
package main

import (
    "context"
    "log"
    "net"

    core "github.com/envoyproxy/go-control-plane/envoy/config/core/v3"
    route "github.com/envoyproxy/go-control-plane/envoy/config/route/v3"
    "github.com/envoyproxy/go-control-plane/pkg/cache/v3"
    "github.com/envoyproxy/go-control-plane/pkg/server/v3"
    "google.golang.org/grpc"
)

func main() {
    snapshotCache := cache.NewSnapshotCache(false, cache.IDHash{}, nil)
    srv := server.NewServer(context.Background(), snapshotCache, nil)

    lis, _ := net.Listen("tcp", ":18000")
    grpcServer := grpc.NewServer()
    // 注册 xDS 服务...
    log.Fatal(grpcServer.Serve(lis))
}

> 💡 经验：APISIX 的 Admin API 最简洁，Kong 次之，Envoy 的 xDS 最复杂但最灵活。

四、插件生态与扩展性对比

| 能力 | Kong | APISIX | Envoy | |——|——|——–|——-| | 官方插件数量 | 80+ | 100+ | 30+（Wasm） | | 自定义插件语言 | Lua | Lua/Java/Go/Wasm | C++/Wasm | | 热更新 | 支持 | 毫秒级 | xDS 动态 | | 限流 | 内置 | 内置 | 需 Filter | | 认证 | JWT/OAuth2 等 | JWT/OAuth2 等 | 需扩展 |

独特见解：如果你的团队以 Java 为主，APISIX 支持 Java 插件（通过 apisix-java-plugin-runner），能极大降低开发成本。


// APISIX Java 插件示例
public class MyPlugin implements PluginFilter {
    @Override
    public void filter(HttpRequest request, HttpResponse response, PluginFilterChain chain) {
        if (request.getPath().startsWith("/api")) {
            request.getHeaders().add("X-Custom", "value");
        }
        chain.filter(request, response);
    }
}

五、选型决策树与最佳实践

5.1 决策树

  1. 团队有 Nginx/Lua 经验？ → 选 Kong 或 APISIX
  2. 需要极致性能 + 服务网格？ → 选 Envoy
  3. 需要快速动态配置 + 丰富插件？ → 选 APISIX
  4. 已有 Istio 生态？ → 选 Envoy
  5. 传统企业，追求稳定？ → 选 Kong

5.2 最佳实践

  • Kong：使用 DB-less 模式 + 声明式配置，避免数据库瓶颈。
  • APISIX：启用 etcd 集群，配置 admin_key 并定期轮换。
  • Envoy：使用 go-control-plane 或 Istio 作为控制平面，避免手写 xDS。

> ⚠️ 踩坑提醒：APISIX 的 X-API-KEY 默认值必须修改，否则存在安全风险。Kong 的 Admin API 默认监听 0.0.0.0:8001，务必加防火墙。

六、总结与下一步

  • Kong：生态成熟，适合传统企业，但性能一般。
  • APISIX：动态能力最强，性能优秀，适合云原生团队。
  • Envoy：性能王者，适合服务网格，但学习成本高。

下一步建议：

  1. 根据本文的压测脚本，在你的环境中复现测试。
  2. 尝试用 APISIX 的 Java 插件开发一个自定义鉴权逻辑。
  3. 如果已有 K8s 集群，部署 Envoy Gateway 体验 xDS 动态配置。

选型没有银弹，适合团队现状的才是最好的。希望本文能帮你少走弯路。

—

延伸阅读：