HMAC、Basic，另外需要对每个认证用户做权限控制，未授权的路由禁止调用| 功能点 | Kong | APISIX | Tky |
|---|---|---|---|
| 社区活跃 | 高，Github有28K的Star | 高，Github有4K的Star | 高，Github有6K的Star |
| 控制台 | 开源版不自带控制台，但有第三方开源控制台支持(konga) | 自带控制台，但实际使用并不友好 | 官方控制台非开源收费 |
| 监控 | 基于prometheus的数据监控，展示route/service/total维度的RPS/带宽/响应时长等指标 | 基于prometheus的数据监控，展示route/service/total维度的RPS/带宽/响应时长等指标 | |
| 路由匹配规则 | Host+Path+Method+Header | 精细化的路由规则匹配，且支持使用Nginx 所有内置变量做为路由的条件 | |
| 鉴权认证 | 支持HMAC、JWT、Basic等认证，支持route/service维度的权限控制 |
HMAC、JWT、Basic等，但权限控制需要额外的服务来支持 |
|
| 配置热更新 | 支持 | 支持 | |
| 限流 | IP/认证用户等多维度限流 | IP/认证用户等多维度限流 | |
| ip黑白名单 | 支持 | 支持 | |
| 负载均衡 | 支持，且提供主动/被动健康检查 | 支持，且提供主动/被动健康检查 | |
| 高性能 | 单核QPS1700(开启限流和 prometheus 插件) | 单核QPS18000(开启限流和 prometheus 插件) | |
| 自定义插件 | 支持(lua)，插件变动需要重启 | 支持(lua)，插件变动支持热更新 |
Kong与APISIX无论是底层原理还是功能实现都非常相近，且以上列出的重要功能点都基本实现了。但实际体验后个人感觉KONG上手更快易于理解，APISIX虽然号称性能更高，但对于我们的应用场景来说实际上单核QPS1700已经完全够用。
另外非常重要的路由授权的实现，APISIX需要额外的服务wolf来实现，且两者存在割裂感，远远不如Kong的使用友好。
如果对性能有极致的要求则使用APISIX，否则个人建议使用Kong。无论是上手易用性还是服务实现完整程度上，个人感觉Kong都略胜与APISIX。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。