API网关与反向代理

为了处理微服务架构，它通常与反向代理（例如nginx或apache httpd）一起使用，并且出于交叉考虑， 使用API​​网关模式。有时反向代理会完成API网关的工作。
很高兴看到这两种方法之间存在明显的差异。看来API网关使用的潜在好处是调用了多个微服务并汇总了结果。API网关的所有其他职责都可以使用反向代理来实现，例如：

• 身份验证（可以使用nginx LUA脚本来完成）；
• 运输安全。它本身就是反向代理任务；
• 负载均衡
• ....

因此，基于此有几个问题：

1. 同时使用API​​网关和反向代理是否有意义（例如request-> Api网关->反向代理（nginx）->具体的mictoservice）？在什么情况下？
2. 使用API​​网关可以实现的其他区别还有反向代理不能实现的其他区别，反之亦然？

如果您意识到它们不是互斥的，则更容易考虑它们。将API网关视为特定类型的反向代理实现。

关于您的问题，经常将两者结合使用时，API网关被视为位于反向代理后面的应用程序层，以进行负载平衡和运行状况检查。一个例子就是类似WAF的三明治体系结构，其中Web应用程序防火墙/ API网关被反向代理层夹持，其中一个反向代理层用于WAF本身，另一个用于与其交谈的单个微服务。

关于差异，它们非常相似。这只是术语。当您进行基本的反向代理设置并开始使用更多功能（例如身份验证，速率限制，动态配置更新和服务发现）时，人们更有可能调用该API网关。

我相信，API网关是一个反向代理，可以通过API以及可能通过UI进行动态配置，而传统的反向代理（例如Nginx，HAProxy或Apache）是通过配置文件配置的，并且在配置更改时必须重新启动。因此，当路由规则或其他配置经常更改时，应使用API​​网关。对您的问题：

1. 只要此序列中的每个组件都能实现其目的，这才有意义。
2. 差异不在功能列表中，而在于配置更改的应用方式。

此外，API网关通常以SAAS的形式提供，例如Apigee或Tyk。

另外，这是我的教程，介绍如何使用Node.js https://memz.co/api-gateway-microservices-docker-node-js/创建简单的API网关

希望能帮助到你。

API网关通常以L7构造形式运行。

与纯反向代理相比，API网关提供了其他功能。如果您考虑那里的某些门户网站，它们可以提供：

• 完整的API生命周期管理，包括文档
• 一个门户，可以用作各种客户端应用程序的真实来源，您可以在其中提供客户端管理，速率限制等。
• 路由到不同版本的API，包括canary / beta版本
• 检测使用模式，注册应用程序，检索客户端凭据等。

但是，随着Istio等服务网格的问世，Consul的许多API网关功能将被网格所包含。