最新出炉！开源 API 网关的性能对比：APISIX 3.0 和 Kong 3.0

背景

云原生时代下，企业逐步向云上迁移，越来越多的应用和服务都在进行容器化改造，服务之间的流量也开端爆发性的增加。为了能高效地管理这些规划庞大的 API，API 网关开端在技术领域大展身手。

用户除了需要 API 网关供给恳求署理、熔断限流、审计监控等惯例能力外，更多开端关注云原生兼容性、支撑场景的多样性，以及更好的功用及稳定性。在这样的背景下，以 Apache APISIX 和 Kong 等为代表的云原生 API 网关项目得到了越来越多开发者的喜爱。

Apache APISIX 是一个云原生、高功用、可扩展的 API 网关，由深圳支流科技捐赠给 Apache 基金会，并于 2020 年 7 月从 Apache 孵化器毕业， 成为 Apache 软件基金会顶级项目。APISIX 基于 NGINX 和 etcd 来完成，和传统 API 网关比较，APISIX 具有动态路由和插件热加载，特别适合云原生架构下的 API 管理。

Kong 也是一款高可用、易扩展的开源 API 网关项目。通过供给署理、路由、负载均衡、身份验证等功用，在微服务与传统 API 领域供给网关层面的支持。

2022 年秋季，Kong 与 Apache APISIX 相继发布了最新的 3.0 版别。其间，Apache APISIX 3.0 要点在生态和架构层面进行了创新与迭代，致力让一切用户都能利用 APISIX 发挥更优异的价值。Kong 3.0 则在新版别中愈加侧重政府、金融业以及对安全合规更关注的大型企业，全体涉及在合规、易用性、功用与功用等方面进行了拓展。

作为开源微服务网关领域的优异作品，在二者几乎同一时间发布 3.0 版别之际，咱们对两个产品进行了一次功用测验，方便读者在挑选和运用这两个网关产品时，对其最新版别的功用体现上有愈加明晰的认知。

测验环境与方式

以下为本次进行测验的方式及环境数据，测验成果仅针对以下环境、机器及特定版别等。 一起本次测验运用 Docker 布置 APISIX 和 Kong 时，将运用 Docker 的 host 网络模式，防止网络原因影响测验成果。以下为其他相关测验装备信息。

恳求拓扑图

以下是测验链路的拓扑图，压力测验东西运用 wrk2，上游服务运用 OpenResty。

相关服务器与软件信息

本次测验将在云服务器上进行，服务器装备为 Standard D8s v3 (8 中心虚拟 CPU，32 GiB 内存) 。一切测验相关组件均布置在这台服务器上，具体服务器环境信息如下表所示。

服务器环境信息
名称	装备
os version	Debian 10 Buster
ulimit -n	65535

测验中所涉及到的软件版别信息如下表所示。

软件名称	版别信息
Docker	20.10.18, build b40c2f6
APISIX	3.0.0
Kong	3.0.0
Upstream	OpenResty 1.21.4.1
Test tool	wrk2

布置细节

咱们挑选 wrk2 作为功用测验东西，挑选 OpenResty 作为模拟上游。用 Docker 来布置 APISIX 与 Kong，而且都启用二者的声明式装备。

在测验时，只开启一个 1 个 worker 进程，这样测验成果会比较直观。正常来说，在实际运用中多个 worker 的负载能力比较 1 个 worker 来说，其功用挨近线性增加。布置脚本与测验脚本可参阅 github.com/api7/apisix…

留意：在测验过程中，APISIX 关闭了 proxy-cache 和 proxy-mirror 插件。这是由于这两个插件的启用将会影响 APISIX 4% 左右的功用（benchmark 相关文档中有提及），因此在本次测验中进行了关闭。

多场景测验与功用比照

场景一：1 条路由，不启用任何插件

场景一旨在测验纯署理场景。因此只设置 1 条路由，不启用任何插件，测验 APISIX 与 Kong 在该场景下的功用差异。

APISIX 装备如下：

routes:
  -
    uri: /hello
    upstream:
      nodes:
        "127.0.0.1:1980": 1
      type: roundrobin
#END

Kong 装备如下：

_format_version: "3.0"
_transform: true
services:
- name: hello
  url: http://127.0.0.1:1980
  routes:
  - name: hello
    paths:
    - /hello

功用比照

在该场景下共进行了 10 轮测验，QPS 如下折线图所示（以 QPS 目标来点评功用）。

从图中能够看到，在纯署理场景下，APISIX 3.0 的功用体现优于 Kong 3.0 之上。APISIX 3.0 的 10 轮 QPS 的平均值为 14104，Kong 3.0 的 10 轮 QPS 的平均值是 9857。比较之下，APISIX 3.0 的功用是 Kong 3.0 的 140%。

场景二：1 条路由 + 1 个插件（限流）

限流是网关产品的首要运用场景之一，因此在场景二中，咱们装备了 1 条路由与 1 个限流插件来满意测验要求。

留意：该场景首要测验网关在限流场景下的功用，其间对限流插件的装备进行了较高的约束，防止触发实际的限流动作。

APISIX 装备如下：

routes:
  -
    uri: /hello
    upstream:
      nodes:
        "127.0.0.1:1980": 1
      type: roundrobin
    plugins:
      limit-count:
        count: 999999999
        time_window: 60
        rejected_code: 503
        key: remote_addr
#END

Kong 装备如下：

_format_version: "3.0"
_transform: true
services:
- name: hello
  url: http://127.0.0.1:1980
  routes:
  - name: hello
    paths:
    - /hello
    plugins:
    - name: rate-limiting
      config:
        minute: 999999999
        limit_by: ip
        policy: local

功用比照

依旧是进行了 10 轮测验，QPS 如下折线图所示（以 QPS 目标来点评功用）。

从上述比照图中能够看到，在启用「约束恳求数量类」的插件后，APISIX 3.0 与 Kong 3.0 的 QPS 都下降显着，可是 Kong 3.0 的 QPS 下降起伏更大。APISIX 3.0 的 10 轮 QPS 的平均值是 9154，Kong 3.0 的 10 轮 QPS 的平均值是 4810，比较之下，APISIX 3.0 的功用是 Kong 3.0 的 190%。

场景三：1 条路由 + 2 个插件（限流+鉴权）

除上述提到的限流功用外，鉴权场景也是网关的首要运用场景之一。因此场景三将两个重要的功用合二为一，装备了 1 条路由的一起，绑定了限流插件和鉴权插件。该场景涵盖了限流与鉴权功用的一起，还在恳求路径中完成了多个插件一起合作工作，覆盖了网关实际运用的经典场景。

APISIX 装备如下：

routes:
  -
    uri: /hello
    upstream:
      nodes:
        "127.0.0.1:1980": 1
      type: roundrobin
    plugins:
      key-auth:
      limit-count:
        count: 999999999
        time_window: 60
        rejected_code: 503
        key: remote_addr
consumers:
  - username: jack
    plugins:
        key-auth:
            key: user-key
#END

Kong 装备如下：

_format_version: "3.0"
_transform: true
services:
- name: hello
  url: http://127.0.0.1:1980
  routes:
  - name: hello
    paths:
    - /hello
    plugins:
    - name: rate-limiting
      config:
        minute: 999999999
        limit_by: ip
        policy: local
    - name: key-auth
      config:
        key_names:
          - apikey
consumers:
- username: my-user
  keyauth_credentials:
  - key: my-key

功用比照

从上述成果折线图中能够看到，APISIX 3.0 在启用 limit-count 和 key-auth 插件后，10 轮 QPS 的平均值为 8933，比较只启用 limit-count 插件时的 QPS 平均值 9154，只有稍微下降（约为 2.4%）。 而 Kong 3.0 在启用 rate-limiting 和 key-auth 插件后，10 轮 QPS 的平均值为 3977，比较只启用 rate-limiting 插件时 QPS 平均值 4810，下降非常显着（约为 17%）。 在该场景下比照 10 轮平均 QPS，APISIX 3.0 的功用是 Kong 3.0 的 220%。

场景四：5000 条路由

该计划运用脚本生成了 5000 条不重复的路由，测验时只射中其间一条路由。该场景首要是测验 APISIX 与 Kong 进行路由匹配时的功用。

功用比照

同样是进行 10 轮测验，成果如上述折线图所示。

从图中能够看到，在该场景下，APISIX 3.0 的 10 轮 QPS 的平均值为 13787，Kong 3.0 的 10 轮 QPS 的平均值为 9840。比较之下，APISIX 3.0 的功用是 Kong 3.0 的 140%，与场景一测验环境下的作用比照相似。

结论

从上述几组测验场景的成果来看：

• 当不在路由上绑定插件时，多路由匹配与单路由纯署理场景下，APISIX 3.0 的全体体现功用为 Kong 3.0 的 140% 左右；
• 当在路由上绑定插件时，APISIX 3.0 的功用为 Kong 3.0 的 200% 左右（有近一倍的功用提高）。

因此在不同场景的功用体现上，APISIX 3.0 全体功用比较 Kong 3.0 而言，仍然保持着较大的优势。假如你对上述两个网关的运用场景有更多运用上的心得，也欢迎随时交流。