我被困在从下面提到的三个 API 网关中选择一个 API 网关：
我的要求是：
从功能列表和性能方面来看，它们三个看起来都不错。我正在考虑放宽第二个要求，因为我不确定这是否是一个好习惯。
API Gateway是一个适用于所有产品的概念，我真的认为业界应该开始对这些产品进行细分，因为它们中的大多数是完全不同的。
我将尝试根据您的要求在这里总结主要亮点。
Kong 和 KrakenD 都提供 API 网关功能的“大部分”。尽管这个词很模糊，但至少它们都涵盖了路由、速率限制、授权等内容。
Kong 基本上是一个 Nginx 代理，它使用 Lua 在其上添加了许多功能。
使用 Kong 时，您的端点与您的后端具有 1:1 的关系。这意味着您在 Kong 中声明一个端点，该端点公开来自一个后端的数据，并在中间发挥作用（授权、限制等）。这种魔法是 Kong 的精髓，它基于 Lua 插件（不幸的是，这些插件不像 Nginx 那样用 C 语言编写）。
如果您想将来自多个后端的数据聚合到一个端点，Kong 不适合您的场景。
最后，Kong 是有状态的（令人印象深刻的是，他们试图以相反的方式出售它，但这超出了这个问题的范围）。配置存在于数据库中，对配置的更改是通过最终修改其内部 Postgres 或等效的 API。
性能也不可避免地与这个数据库（和 Lua）的存在相关联，并且多区域可能是一个真正的痛苦。
Kong 功能可以使用 Lua 代码进行扩展。
总之：
KrakenD 是使用 Go 从头开始编写的服务，利用语言特性实现并发性、速度和占用空间小。在性能方面，这是获胜的赛马。
KrakenD 的天然定位是作为具有聚合的网关。它旨在将大量后端服务连接到单个端点。它主要被公司用于提供移动应用程序、Webapps 和其他客户端。它为前端实现了后端模式，允许您使用声明性配置准确定义要向客户端公开的 API。您可以选择从响应中获取哪些字段、聚合它们、验证它们、转换它们等。
KrakenD 是无状态的，您可以使用 git 以与处理其余代码相同的方式对 API 进行版本控制。并且您以与您的应用程序相同的方式部署它（例如：一个 CI/CD 管道，它使用新配置推送一个新容器并推出）。由于一切都在配置中，因此不需要中央数据库，节点之间也不需要相互通信。
根据自定义设置，使用 KrakenD，您可以创建中间件、插件或仅使用多种语言编写脚本：Go、Lua、通用表达式语言 (CEL) - 某种 JS- 和 Martian DSL。
总之：
（以及Zuul）主要由想要坚持 JVM 空间的 Java 开发人员使用。我对这个不太熟悉，但它的设计也是为了代理现有服务，也增加了 API 网关的交叉问题。
我将其更多地视为您用来交付 API 的框架。使用此产品，您需要自己用 Java 编写转换代码。包含的网关功能也是声明性的。
--
我希望这能有所启发
我使用 Kong 的唯一主要障碍是您只能使用 LUA 扩展 Kong。世界上只有一小部分开发人员熟悉 LUA。这就是我选择 KrakenD 的原因。