阿里云API网关（不要告诉别人）网关和api的区别，开源 API 网关的性能对比：APISIX 3.0 和 Kong 3.0，

1.阿里云api网关

作者 | 屠正松 苏钰 责编 | 梦依丹出品 | APISIX 技术团队投稿云原生时代下，企业逐渐向云上迁移，越来越多的应用和服务都在进行容器化改造，服务之间的流量也开始爆发性的增长为了能高效地管理这些规模庞大的 API，API 网关开始在技术领域大展身手。

2.阿里云api网关中,默认调用api的流控限制

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

3.阿里云api网关使用

Apache APISIX 是一个云原生、高性能、可扩展的 API 网关，由深圳支流科技捐赠给 Apache 基金会，并于 2020 年 7 月从 Apache 孵化器毕业， 成为 Apache 软件基金会顶级项目。

4.阿里云api网关和csb

APISIX 基于 NGINX 和 etcd 来实现，和传统 API 网关相比，APISIX 具备动态路由和插件热加载，特别适合云原生架构下的 API 管理Kong 也是一款高可用、易扩展的开源 API 网关项目。

5.阿里云api网关 收费标准

通过提供代理、路由、负载均衡、身份验证等功能，在微服务与传统 API 领域提供网关层面的支持2022 年秋季，Kong 与 Apache APISIX 相继发布了最新的 3.0 版本其中，Apache APISIX 3.0 重点在生态和架构层面进行了创新与迭代，致力让所有用户都能利用 APISIX 发挥更优秀的价值。

6.阿里云api网关中,默认调用api的流控限制为单个

Kong 3.0 则在新版本中更加侧重政府、金融业以及对安全合规更关注的大型企业，整体涉及在合规、易用性、功能与性能等方面进行了拓展作为开源微服务网关领域的优秀作品，在二者几乎同一时间发布 3.0 版本之际，我们对两个产品进行了一次性能测试，方便读者在选择和使用这两个网关产品时，对其最新版本的性能表现上有更加清晰的认知。

7.阿里云api网关 dubbo

测试环境与方式以下为本次进行测试的方式及环境数据，测试结果仅针对以下环境、机器及特定版本等同时本次测试使用 Docker 部署 APISIX 和 Kong 时，将使用 Docker 的 host 网络模式，避免网络原因影响测试结果。

8.阿里云api网关和csb区别

以下为其他相关测试配置信息请求拓扑图以下是测试链路的拓扑图，压力测试工具使用 wrk2，上游服务使用 OpenResty。

9.阿里云api网关 jwt插件

相关服务器与软件信息本次测试将在云服务器上进行，服务器配置为 Standard D8s v3 (8 核心虚拟 CPU，32 GiB 内存) 所有测试相关组件均部署在这台服务器上，具体服务器环境信息如下表所示。

10.阿里云api网关可以每次请求换ip

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

部署细节我们选择 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: trueservices:- 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: trueservices:- 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: trueservices:- 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 而言，仍然保持着较大的优势。

如果你对上述两个网关的使用场景有更多使用上的心得，也欢迎随时交流☞