我被迫从下面提到的三个API网关中选择一个API网关：
我的要求是：
它们全部三个，从功能列表和性能方面来看都不错。我不确定，这是否是一种好习惯，我想放宽第二个要求。
API Gateway是用于所有产品的概念，我真的认为行业应该开始对这些产品进行子分类，因为它们中的大多数彼此完全不同。
我将根据您的要求在这里总结主要要点。
Kong和KrakenD都提供了API网关功能的“多数”。尽管这个词很模糊，但至少它们全部涵盖诸如路由，速率限制，授权等内容。
Kong基本上是一个Nginx代理，它使用Lua在其之上添加了很多功能。
使用Kong时，您的端点与后端具有1：1的关系。这意味着您在Kong中声明一个端点，该端点公开来自一个后端的数据，并在中间进行操作（授权，限制等）。这种魔力是Kong的本质，它基于Lua插件（不幸的是，它们不像Nginx那样用C编写）。
如果要将多个后端的数据聚合到一个端点中，则Kong不适合您的情况。
最后，Kong是stateful（他们如何尝试以其他方式出售它令人印象深刻，但这不在此问题的范围内）。该配置位于数据库中，并且通过API对该配置进行更改，该API最终修改了其内部Postgres或等效版本。
性能也不可避免地与该数据库（和Lua）的存在联系在一起，而进入多区域可能是一个真正的痛苦。
Kong功能可以用Lua代码扩展。
摘要：-具有跨领域关注的代理-节点需要协调和同步-可变配置-数据库是真理的源头-更多作品，更复杂-多区域滞后-需要强大的硬件才能运行-Lua中的自定义
KrakenD是一项使用Go从头开始编写的服务，它充分利用了并发，速度和占用空间小的语言功能。就性能而言，这是获胜的赛马。
KrakenD的自然定位是作为具有聚合功能的网关。这意味着将许多后端服务连接到单个端点。公司主要采用它来提供移动应用程序，Webapps和其他客户端。它实现了Backend for Frontend模式，使您可以准确地定义并使用声明式配置来向客户端公开API。您可以选择从响应中获取哪些字段，对其进行汇总，对其进行验证，对其进行转换等。
KrakenD is stateless，您使用git对API的其余部分进行版本化。然后以与应用程序相同的方式部署它（例如：CI / CD管道，该管道使用新配置推送新容器并推出）。因为所有内容都在配置中，所以不需要中央数据库，两个节点都不需要相互通信。
根据定制，您可以使用KrakenD创建中间件，插件或仅使用以下几种语言编写脚本：Go，Lua，通用表达语言（CEL）-JS-和Martian DSL。
摘要：-使用具有跨领域关注点的上游服务动态创建API（API网关）。-不是代理，尽管可以用作代理。-无节点协调-无需同步-零复杂度（带有配置文件的docker容器）-多区域无挑战-声明式配置-不变的基础设施-在生产中的微型和小型机器上运行不会出现问题。-Go，Lua，CEL和Martian DSL中的自定义]
（以及Zuul）通常由希望坚持JVM空间的Java开发人员使用。我对此不太熟悉，但是它的设计还用于代理现有服务，还增加了API网关的交叉关注。
我将其更多地看作是用于提供API的框架。使用此产品，您需要自己用Java编写转换代码。包含的网关功能也具有声明性。
-
我希望这能阐明一些信息