API网关简介
传统的网站服务框架中，一般会使用 nginx 进行路由转发、反向代理和负载均衡，类似身份认证、限流限速等功能，由上游服务自身来完成。随着网络规模不断地增涨，微服务的出现以及API数量增多，上游服务重复地实现身份认证、限流限速、日志等通用的功能，严重浪费开发资源，增加升级维护成本。API网关的出现，解决了这些问题。
API 网关是流量的入口，负责把终端的 API 请求路由到正确的上游服务进行处理，然后再把返回的数据返回给原始请求方，同时保证整个过程的安全、可靠和低延迟。有了API网关之后，各个API服务可以专注于自己的业务逻辑处理，而API网关则更专注于安全、流量、路由、负载均衡等问题。
APISIX 和 Kong 都是云原生、高性能、可扩展的开源微服务 API 网关，底层都是基于nginx。
本文将通过社区活跃度、产品成熟的、性能、 等维度来对APISIX 和 KONG进行对比。
社区活跃度
贡献者数量
APISIX 的贡献值多于KONG, 并且APISIX 贡献值的增长速度远大于KONG。
贡献者活跃度
KONG 贡献者月活人数在10~20人之间，APISIX 贡献者月活人数基本大于20。
提交数量
apisix
kong
APISIX 和KONG 的平均提交数量相差不大。
产品成熟度（主要看采用案例）
根据HG Insights网站统计，有3700+公司正在使用KONG。APISIX 的用户有很多都是国内公司，在中国的互联网环境中，有庞大的用户群体和相对集中的请求流量。所以APISIX 和 KONG 都是成熟的产品，在各自的网站上均列出了很多使用案例。
功能（插件丰富度）
| 功能分类 | 细分类 | APISIX | KONG |
|---|---|---|---|
| 认证鉴权 | key-auth, jwt-auth, basic-auth, authz-keycloak,authz-casbin, authz-casdoor, wolf-rbac, openid-connect, cas-auth, hmac-auth, ldap-auth, opa, forward-auth | jwt-auth, basic-auth, hmac-auth, ldap-auth, oauth, session, okta,paseto, | |
| 安全 | cors,uri-blocker,ip-restriction,ua-restriction,referer-restriction,consumer-restriction, csrf,public-api | ACME, Bot detection, cors, ip-restriction, Cleafy plugin for Kong | |
| 流量控制 | limit-req,limit-conn,limit-count,proxy-cache,request-validation,proxy-mirror， api-breaker, traffic-split,request-id,proxy-control,client-contorl | rate-limit， ACL, proxy-cache, request-termination,, reqponse-rate-limiting, | |
| Serverless | serverless,azure-functions, openwhisk，openfunction，aws-lambda,workflow | openwhisk，aws-lambda, serverless-function, azure-functions | |
| 可观测性 | 日志 | httplogger,skywalking-logger,tcp-logger,kafka-logger,rocketmq-logger,udp-logger,clickhouse-logger,syslog,log-rotate,error-log-logger,sls-logger,google-cloud-logging,splunk-hec-logging,file-logger,loggly,elasticsearch-logger,tencent-cloud-cls | file-log, http-log,loggly,syslog,tcplog,udplog,kong google cloud logging |
| 指标 | datadog，prometheus，node-status | datadog，prometheus，StatsD | |
| 链路 | zipkin，skywalking，opentelemetry | zipkin，opentelemetry | |
| 多协议接入 | subbo-proxy,mqtt-proxye,kafka-proxy | ||
| 请求变形 | Response-Rewrite,Proxy-rewrite,grpc-transcode,grpc-web,falt-injection,mocking | correlation-id,grpc-gateway,grpc-web,jq,request-transformer,response-transformer, |
（左滑查看完整表格）
| 功能 | APISIX | KONG |
|---|---|---|
| 反向代理和路由 | 支持 | 支持 |
| 负载均衡 | 支持 | 支持 |
| 身份验证和授权 | 支持 | 支持 |
| IP列表白名单/黑名单 | 支持 | 支持 |
| 限速和流控 | 支持 | 支持 |
| 请求变形 | 支持 | 支持 |
| 版本控制 | 支持 | 支持 |
| 断路器 | 支持 | 支持 |
| 多协议支持 | 支持 | 支持 |
| 缓存 | 支持 | 支持 |
| 数据库存储 | etcd | Postgres/Cassandra |
（左滑查看完整表格）
APISIX 和 KONG 的插件都能够满足基本使用，但APISIX 的插件数量更多，功能更加丰富，而且KONG 的部分插件只能在付费版上使用。
性能测试
压测环境
- 软件版本：APISIX 2.15, KONG 3.0.0
- Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz 32核 64GB
- 测试方法：分别开启指定 worker 数量（单核、多核），用 wrk 压力测试。要保证上游服务正常，无瓶颈
- 分别开启 limit-req 和 key-auth 插件对比测试
测试结果
| 测试场景 | API网关 | qps | worker cpu | system cpu | sys memory | worker mem | net(IN) | net(OUT) |
|---|---|---|---|---|---|---|---|---|
| 1woker 0plugin | APISIX | 13641.39 | 100% | 2% | 7.9% | 0.1% | 8.7MB/s | 9.5MB/s |
| KONG | 10706.01 | 100% | 3.57% | 7.76% | 0.2% | 7.19MB/s | 8.3MB/s | |
| 1worker limit-req | APISIX | 12635.08 | 100% | 2.53% | 7.92% | 0.1% | 6.7MB/s | 7.5MB/s |
| KONG | 4565.89 | 100% | 2.73% | 7.8% | 0.3% | <10Mb/s | <10MB/s | |
| 1worker key-auth | APISIX | 11284.50 | 100% | 2.18% | 7.9% | 0.1% | 9.1MB/s | 10.3MB/s |
| KONG | 7592.20 | 100% | 2.76% | 7.79% | 0.3% | <10MB/s | <10MB/s | |
| 4worker 0plugin | APISIX | 44704.12 | 400% | 5.99% | 8.04% | 0.4% | 28MB/s | 31MB/s |
| KONG | 32553.66 | 400% | 8.07% | 8.51% | 1.2% | 18MB/s | 21MB/s | |
| 4worker limit-req | APISIX | 40184.87 | 400% | 5.67% | 8% | 0.4% | 25MB/s | 28MB/s |
| KONG | 16405.04 | 400% | 7.93% | 8.46% | 1.2% | 16.1MB/s | 19MB/s | |
| 4worker key-auth | APISIX | 40128.34 | 400% | 5.72% | 8.02% | 0.4% | 25.2MB/s | 28MB/s |
| KONG | 24904.76 | 400% | 8.46% | 8.86% | 1.2% | 16.2MB/s | 21MB/s |
（左滑查看完整表格）
通过性能测试可以看到，在不开启插件的情况下，APISIX 的性能大约为KONG 性能的1.3倍；开启插件后，APISIX 和 KONG 的性能都有所下降，但是APISIX 的性能损失不明显，KONG 的性能损失相对较大。
二次开发便捷性
KONG 和 APISIX 虽然提供了不少插件，涵盖了大部分网关的使用场景，但企业在使用时，仍然需要根据业务需求做定制功能。二者都支持使用lua 开发原生插件。使用lua 语言开发插件的优势在于性能好，但由于lua 属于相对小众语言，开发者需要付出一定的学习成本。
此外，KONG 和 APISIX 还可以通过 Plugin Runner 来支持更多的主流编程语言开发插件，这一类插件可以称之为外部插件。网关会以子进程的方式运行 Plugin Runner，网关worker 与 Plugin Runner 通过本地RPC 进行通信。这种方式减少了开发成本，提高了开发效率，但是在性能上会有一些损失。
开发者还尝试了其他方式，使插件开发即达到lua原生插件的性能，又可以达到高级编程语言的开发效率。WebAssembly 是一种新的编码方式，可以在现代的网络浏览器中运行 － 它是一种低级的类汇编语言，具有紧凑的二进制格式，可以接近原生的性能运行。开发者可以利用 WebAssembly 将插件代码编译成WebAssembly 字节码，然后在APISIX 中运行。
| gateway | APISIX | KONG |
|---|---|---|
| 原生插件开发语言 | lua | lua |
| 其他开发语言 | go，python，Java， Node | go，Pyhton， Javascript |
| wasm | 支持 | 暂不支持 |
云原生环境适配性（ingress、函数计算等）
ingress
云原生架构出现后，微服务都以容器的形式运行，容器内外地址不同，使用 ingress 将集群内的服务暴露到集群外。
在 K8s 生态中，Ingress 作为表示 K8s 流量入口的一种资源，想要让其生效，就需要有一个 Ingress Controller 去监听 K8s 中的 Ingress 资源，并对这些资源进行相应规则的解析和实际承载流量。
使用KONG 作为 Kubernetes 的 ingress 时， KONG 作为处理流量的核心代理，此外还需要Controller 来从 Kubernetes 中同步配置到KONG 。
apisix-ingress-controller是Kubernetes的另一个Ingress控制器，使用 APISIX 作为高性能反向代理。它是通过使用诸如 ApisixRoute、 ApisixUpstream 和 Inress 之类的声明性配置进行配置的。在 APISIX 中，所有这些资源都被监视并转换为相应的资源。
函数计算集成
在无服务时代，API 网关依旧是管理和充分利用无服务器平台的关键。函数计算是一个事件驱动的服务。函数的执行可以由事件驱动，即当某个事件发生时，该事件触发函数的执行。现在，函数计算支持以 API 网关作为事件源。当请求设置函数计算为后端服务的 API 时，API 网关会触发相应的函数，函数计算会将执行结果返回给 API 网关。
APISIX 和 KONG 提供了常用云厂商的函数计算相关插件。将函数作为动态上游集成至 API网关，从而实现将访问指定 URI 的请求代理到对应的云服务。当网关收到请求时，相应的插件会终止对已配置 URI 的请求，并代表客户端向 function 发起一个新的请求，然后插件会将响应信息返回至客户端。
API 网关与函数计算对接，可以以 API 形式安全地对外开放函数，并且解决认证、流量控制、数据转换等问题。
总结
1. APISIX 社区活跃度略好于KONG；
2. APISIX 软件性能好于 KONG；
3. APISIX 功能更加丰富，插件多；
4. APISIX 与KONG 都支持多语言插件开发，支持进度APISIX 略好；
5. APISIX 与KONG 都属于云原生网关，适配性好。