Node.js API 网关和 nginx 作为反向代理

Posted 2023-03-08

【中文标题】Node.js API 网关和 nginx 作为反向代理

【英文标题】：Node.js API Gateway & nginx as reverse proxy

【发布时间】：2018-10-24 07:56:17

【问题描述】：

我最近开始使用微服务架构创建一个应用程序，随着应用程序发展，划分反向代理和 API 网关的概念对我来说逐渐消失： 我想使用 nginx 来处理负载平衡和反向代理，但我也想使用 API 网关，因此客户端不知道架构中的每个微服务（除其他外）。

所以现在我被鸡和蛋的问题困住了，我一直在思考什么是第一：

请求 > API 网关 > nginx。 请求 > nginx > API 网关。

我倾向于认为它的编号是 1，但在这种情况下，nginx 不会是应用程序的入口点...（这是一个问题吗？）

【问题讨论】：

查看类似的通用问题***.com/questions/35756663/…

【参考方案1】：

理想情况下，您应该选择选项 2。原因如下：

API 网关通常不是为处理潜在的 DOS 攻击而设计的，拥有网关的 nginx 信息可以消除这种担忧。

大多数 API 网关都是基于路由的，如果您选择子域，选项 1 仅适用于某些网关，但 2 将适用于所有网关。

像 nginx 这样的反向代理在构建时考虑到了性能，并且可以以更低的成本处理更多的请求。在性能更高的服务器前面安装 Node.js 是一个瓶颈！

API 网关在技术上是一种“专门的”反向代理。所以最终你会意识到任务可以由任何一方执行。

【参考方案2】：

API 网关具有许多功能，例如限制、缓存、cors 等。许多使用 API 网关来调用不同的微服务并在 API 网关级别组合结果（虽然我不喜欢它）。您还可以使用一些 API 网关工具进行 API 版本管理。

只有在您决定调用哪个 API 或阻止该 API 或调用哪个 API 版本之后，才应该进行负载平衡。

所以选项 1 对我来说是正确的。

【讨论】：

我同意你的观点，但在这一部分“许多人使用 API 网关调用不同的微服务并在 API 网关级别组合结果（虽然我不喜欢它）。” - 那你会怎么做？组合 20 个微服务的轻量级结果然后发回一个响应而不是发回 20 个单个响应不是更好吗？

我会有一个微服务，调用剩下的 19 个。在 API 网关层组合的问题很难调试，不是源代码控制的一部分，而且还有一个可以调试的地方，以防万一一个错误。