背景

雲原生時代下，企業逐漸向雲上遷移，越來越多的應用和服務都在進行容器化改造，服務之間的流量也開始爆發性的增長。為了能高效地管理這些規模龐大的 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 內存) 。所有測試相關組件均部署在這台服務器上，具體服務器環境信息如下表所示。

測試中所涉及到的軟件版本信息如下表所示。

部署細節

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

在測試時，只開啓一個 1 個 worker 進程，這樣測試結果會比較直觀。正常來説，在實際使用中多個 worker 的負載能力相比 1 個 worker 來説，其性能接近線性增長。部署腳本與測試腳本可參考 https://github.com/api7/apisix-benchmark。

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

關於 API7.ai 與 APISIX

API7.ai（支流科技）是一家提供 API 處理和分析的開源基礎軟件公司，於 2019 年開源了新一代雲原生 API 網關 -- APISIX 並捐贈給 Apache 軟件基金會。此後，API7.ai 一直積極投入支持 Apache APISIX 的開發、維護和社區運營。與千萬貢獻者、使用者、支持者一起做出世界級的開源項目，是 API7.ai 努力的目標。