Krakend 与 Kong 相比有多好？

Question

我一直在从下面提到的三个 API 网关中选择一个 API 网关：

我的要求是：

所有这三个，从功能列表和性能方面看起来都不错。我正在考虑放宽第二个要求，因为我不确定这是否是一个好的做法。

Answer 1

API Gateway是一个被用于各种产品的概念，我真的认为行业应该开始对这些产品进行细分，因为它们中的大多数彼此完全不同。

我将尝试在此处根据您的要求总结主要亮点。

Kong 和 KrakenD 都提供了 API 网关功能的“大部分”。虽然这个词很模糊，但至少它们都涵盖了路由、速率限制、授权等内容。

孔

Kong 基本上是一个 Nginx 代理，它使用 Lua 在它之上添加了许多功能。

使用 Kong 时，您的端点与后端是 1:1 的关系。这意味着您在 Kong 中声明了一个端点，该端点从一个后端公开数据，并在中间发挥作用（授权、限制等）。这种魔法是 Kong 的精髓，它基于 Lua 插件（不幸的是，这些插件不像 Nginx 那样用 C 编写）。

如果您想将来自多个后端的数据聚合到一个端点中，Kong 不适合您的场景。

最后，Kong 是有状态的（令人印象深刻的是他们试图以相反的方式出售它，但这超出了本问题的范围）。配置位于数据库中，对配置的更改是通过 API 进行的，该 API 最终会修改其内部 Postgres 或等效项。

性能也不可避免地与这个数据库（和 Lua）的存在相关联，多区域可能是一个真正的痛苦。

可以使用 Lua 代码扩展 Kong 功能。

总之：

KrakenD 是一种使用 Go 从头开始编写的服务，利用了并发性、速度和占用空间小的语言特性。就性能而言，这是获胜的赛马。

KrakenD 的自然定位是作为具有聚合的网关。它旨在将大量后端服务连接到单个端点。它主要被公司用于提供移动应用程序、Webapps 和其他客户端。它为前端实现了模式后端，允许您使用声明性配置准确定义要向客户端公开的 API。您可以选择从响应中获取哪些字段、聚合它们、验证它们、转换它们等。

KrakenD 是无状态的，您可以使用 git 以与处理其余代码相同的方式对 API 进行版本控制。并且您以与应用程序相同的方式部署它（例如：CI/CD 管道，它使用新配置推送新容器并推出）。由于一切都在配置中，因此不需要中央数据库，两个节点都不需要相互通信。

根据自定义，使用 KrakenD，您可以创建中间件、插件或仅使用多种语言编写脚本：Go、Lua、通用表达式语言 (CEL) - 某种 JS- 和 Martian DSL。

总之：

（以及Zuul）主要由想要留在 JVM 空间的 Java 开发人员使用。我对这个不太熟悉，但它的设计也是为了代理到现有服务，还增加了 API 网关的交叉问题。

我更多地将其视为用于交付 API 的框架。使用此产品，您需要自己用 Java 编写转换代码。包含的网关功能也是声明性的。

——

我希望这能带来一些启示

@alo 我相信 Kong 的答案对于状态性来说已经过时了。Kong 提供了无数据库模式，您可以将配置作为 yaml 配置文件提供。无需数据库。因此，可以保留具有完整 Kong 配置的 git 存储库。当然，并非所有插件等都支持无数据库模式。 (2认同)