开源 API 网关的性能对比:APISIX 3.0 和 Kong 3.0
作者 | 屠正松 苏钰 责编 | 梦依丹
出品 | APISIX 技术团队投稿
云原生时代下,企业逐渐向云上迁移,越来越多的应用和服务都在进行容器化改造,服务之间的流量也开始爆发性的增长。为了能高效地管理这些规模庞大的 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 指标来评价性能)。
图1
从图1中可以看到,在纯代理场景下,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 指标来评价性能)。
图2
从上述对比图中可以看到,在启用「限制请求数量类」的插件后,APISIX 3.0 与 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_addrconsumers: - 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: - apikeyconsumers:- username: my-user keyauth_credentials: - key: my-key
性能对比
图3
从上述结果折线图中可以看到,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 进行路由匹配时的性能。
性能对比
图4
同样是进行 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 而言,仍然保持着较大的优势。
一堂高质量的API网关技术课
《从0开始打造自己的API网关》
(扫描下方二维码了解专栏详情)
15期图文专栏,仅售29.9元!
✔ 设计+实践+部署,全流程指导
✔ 带你动手开发轻量级API网关
每一讲中都会为你讲解实现过程和细节,并阐述每个设计的思路和原理,希望你在学习后,不仅可以系统性地掌握API网关的工作原理和开发技能,更能懂得API网关开发的思考过程和设计思路,从而达到举一反三的效果。
▼ 扫码试学 ▼
发布:刘恩惠
审核:陈歆懿
相关文章
- 体验极致推理性能!30分钟带你快速掌握AI开发与边缘部署
- 国科大&港中文提出带视觉语言验证和迭代推理的Visual Grounding框架,性能SOTA,代码已开源!(CVPR2022)
- 开源|ftlog升级啦!功能更强,性能更高,细节更极致
- 【SLAM】开源 | 利用局部3D深度描述符进行环路闭合检测,性能SOTA!
- 【SLAM】开源 | 一种基于surfel的建图方法,相比于纯几何法性能SOTA!
- 【文本识别】开源 | 基于几何感知的高效文本识别,模型权重小、推理时间短、可靠性强,性能SOTA!
- 开源的DPU “Helium”,给性能不足的服务器安上“外挂”!
- 开源实时监控系统CAT 3.0发布:多语言客户端及多项性能提升
- 开源性能监控工具atop【字节跳动版本】的安装与简单使用
- 使用Go开源的一款性能监控软件
- toString性能就一定低吗?
- 从 Java 的角度看待 Go 的编码规范和性能调优| 青训营笔记
- 开源高度定制化 Git 工作流工具,上手简单,功能强大,性能优异
- 只需单插槽的空间,即可拥有极致的视觉计算性能
- 速度、准确率与泛化性能媲美SOTA CNN,Facebook开源高效图像Transformer
- 强制SQL Server执行计划使用并行提升在复杂查询语句下的性能
- 开创MySQL性能新纪元:高性能MySQL第四版(高性能mysql第四版)
- 系统Linux分支系统:探索开源世界的性能优势(linux的分支)
- 使用开源工具识别 Linux 的性能瓶颈
- 提升Oracle并发查询性能的策略(oracle并发查询)
- 优化MySQL并发更新操作:提高数据库性能(mysql并发更新)
- Linux IRQ中断:释放你的计算机性能(linuxirq中断)
- Oracle数据库内存合理配置优化性能(oracle内存合理设置)
- 什么开源Redis弹性伸缩的极限性能(开源redis的优点是)
- API技术提高MySQL数据库性能(api和mysql)
- 分析何时使用Redis合理灵活提升系统性能(何时使用redis)
- Oracle 9i 92突破性技术极大提升数据库性能(oracle9i 9.2)