Microservices 与香港相比，克拉肯德有多好？

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

克拉肯德（）

孔（）

Spring云网关（）

我的要求是：

性能良好，必须具备大多数API网关功能

支持聚合来自两个不同微服务API的数据

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

API网关是一个用于所有类型产品的概念，我真的认为业界应该开始对这些产品进行细分，因为它们中的大多数彼此完全不同

我将根据您的要求在这里总结主要亮点

Kong和KrakenD都提供“大部分”API网关功能。虽然这个词很模糊，但至少所有这些词都包括路由、速率限制、授权等内容

香港 Kong基本上是一个Nginx代理，它使用Lua在上面添加了很多功能

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

如果要将多个后端的数据聚合到一个端点中，则Kong不适合您的场景

最后，香港是一个富于状态的国家（令人印象深刻的是，他们试图以另一种方式出售它，但这超出了这个问题的范围）。配置存在于数据库中，对配置的更改是通过一个API完成的，该API最终会修改其内部Postgre或等效项

性能也不可避免地与该数据库（和Lua）的存在联系在一起，而跨区域可能是一个真正的难题

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

总之：

• 具有交叉关注点的代理
• 节点需要协调和同步
• 可变配置
• 数据库是真相的来源
• 作品越多，就越复杂
• 多区域滞后
• 需要强大的硬件才能运行
• Lua中的定制

克拉肯德 KrakenD是一个使用Go从头编写的服务，它利用了语言的并发性、速度和占用空间小的特点。就性能而言，这是一匹获胜的赛马

克拉肯德的自然定位是作为一个聚合的门户。它意味着将许多后端服务连接到单个端点。它主要被公司用于为移动应用程序、网络应用程序和其他客户提供服务。它实现了前端的模式后端，允许您使用声明性配置准确地定义要向客户机公开的API。您可以选择从响应中获取哪些字段、聚合它们、验证它们、转换它们，等等

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

根据定制，使用KrakenD，您可以创建中间件、插件或仅使用几种语言编写脚本：Go、Lua、Common Expression Language（CEL）——类似于JS——和火星DSL

总之：

• 使用上游服务动态创建API，带有横切关注点（API网关）
• 不是代理，尽管它可以用作代理
• 无节点协调
• 不需要同步
• 零复杂性（带有配置文件的docker容器）
• 多地区无挑战
• 声明性配置
• 不变的基础设施
• 在生产中的微型和小型机器上运行，没有问题
• Go、Lua、CEL和火星DSL中的定制

春云之门 （以及）主要由希望留在JVM空间的Java开发人员使用。我对这个不太熟悉，但它的设计也是为了代理现有的服务，这也增加了API网关的交叉关注点

我认为它更像是一个用于交付API的框架。使用此产品，您需要自己用Java编写转换代码。所包含的网关功能也是声明性的

--

---

我希望这能给我一些启示

我使用金刚的唯一和主要障碍是你只能用LUA扩展金刚。世界上只有一小部分开发人员熟悉LUA。这就是我选择KrakenD的原因。

您选择了什么？我认为值得注意的是，当您更改配置时，KrakenD需要重新启动，没有热重新加载。有一种方法，如果配置文件发生更改，它将自动重新启动，请参见@tobiaserikson。与其他服务器一样，更改配置需要重新启动服务。它认为现在没有任何问题（例如：蓝色/绿色部署），我建议不要使用生产链接中描述的系统。