從 API 網關核心功能點來看，兩者均已覆蓋：
| 功能 | Apache APISIX | Kong |
|---|---|---|
| 動態上游 | 支持 | 支持 |
| 動態路由 | 支持 | 支持 |
| 健康檢查和熔斷器 | 支持 | 支持 |
| 動態SSL證書 | 支持 | 支持 |
| 七層和四層代理 | 支持 | 支持 |
| 分布式追蹤 | 支持 | 支持 |
| 自定義插件 | 支持 | 支持 |
| REST API | 支持 | 支持 |
| CLI | 支持 | 支持 |
更詳細的比較：
| 功能 | Apache APISIX | Kong |
|---|---|---|
| 項目歸屬 | Apache 軟件基金會 | Kong Inc. |
| 技術架構 | Nginx + etcd | Nginx + postgres |
| 交流渠道 | 微信群、QQ群、郵件列表、Github、meetup | Github、論壇、freenode |
| 單核QPS(開啟限流和premetheus插件) | 18000 | 1700 |
| 平均延遲 | 0.2毫秒 | 2毫秒 |
| 配置生效時間 | 事件通知，低於1毫秒更新 | 定期輪詢，5秒 |
| 支持 Dubbo 代理 | 是 | 否 |
| 配置回滾 | 是 | 否 |
| 支持生命周期的路由 | 是 | 否 |
| 插件熱更新 | 是 | 否 |
| 用戶自定義：負載均衡算法、路由 | 是 | 否 |
| resty <--> gRPC 轉碼 | 是 | 否 |
| 支持 Tengine 作為運行時 | 是 | 否 |
| MQTT 協議支持 | 是 | 否 |
| 自帶控制台 | 是 | 否 |
| 對接外部身份認證服務 | 是 | 否 |
| 配置中心高可用（HA） | 是 | 否 |
| 指定時間窗口的限速 | 是 | 否 |
| 支持任何 Nginx 變量做路有條件 | 是 | 否 |
壓測環境
測試平台：阿里雲 ecs.hfg5.2xlarge 8 vCPU 32 GiB。
測試方法：分別開啟指定 worker 數量（單核、多核），然后用 wrk 加大壓力測試。這里要把 API 網關資源打滿（主要是 CPU）。而壓測客戶端、上游服務都正常服務，不是瓶頸。
開啟 prometheus 和 limit-count 兩個插件。
測試版本：Apache APISIX 0.9 和 Kong 1.4.3
測試腳本：https://gist.github.com/membphis/137db97a4bf64d3653aa42f3e016bd01
壓測場景 1：只開啟一個 worker
詳細壓測結果（大家可以這里的腳本，自己來重現性能測試的結果）
** Apache APISIX 在不開啟插件，只做反向代理的情況下，是 Kong QPS 的 2 倍；在開啟限流和prometheus這兩個插件后，性能是 Kong 的 10 倍。 **
** Apache APISIX 在不開啟插件，只做反向代理的情況下，是 Kong 延遲的一半；在開啟限流和prometheus這兩個插件后，延遲是 Kong 的十分之一。**
壓測場景 2：開啟 4 個 worker
詳細壓測結果
通過性能測試可以看到，在不開啟插件的情況下，Apache APISIX 的性能（QPS 和延遲）是 Kong 的2倍，但開啟了兩個常用插件后，性能就是 Kong 的十倍了。