最新出爐！開源 API 閘道器的效能對比：APISIX 3.0 和 Kong 3.0

Apache_APISIX發表於2022-11-22
API

背景

雲原生時代下，企業逐漸向雲上遷移，越來越多的應用和服務都在進行容器化改造，服務之間的流量也開始爆發性的增長。為了能高效地管理這些規模龐大的 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 versionDebian 10 Buster
ulimit -n65535

測試中所涉及到的軟體版本資訊如下表所示。

軟體名稱版本資訊
Docker20.10.18, build b40c2f6
APISIX3.0.0
Kong3.0.0
UpstreamOpenResty 1.21.4.1
Test toolwrk2

部署細節

我們選擇 wrk2 作為效能測試工具，選擇 OpenResty 作為模擬上游。用 Docker 來部署 APISIX 與 Kong，並且都啟用二者的宣告式配置。

在測試時，只開啟一個 1 個 worker 程式，這樣測試結果會比較直觀。正常來說，在實際使用中多個 worker 的負載能力相比 1 個 worker 來說，其效能接近線性增長。部署指令碼與測試指令碼可參考 https://github.com/api7/apisi...。

注意：在測試過程中，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 而言，仍然保持著較大的優勢。如果你對上述兩個閘道器的使用場景有更多使用上的心得，也歡迎隨時交流。

相關文章