API网关与反向代理

Question

为了处理微服务架构，它通常与反向代理（例如nginx或apache httpd）一起使用，并且用于横切关注实现API gateway pattern is used。有时反向代理执行API网关的工作。
很高兴看到这两种方法之间存在明显的差异。 看起来API网关使用的潜在好处是调用多个微服务并聚合结果。 API网关的所有其他responsibilities可以使用反向代理实现。例如：

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

基于此，有几个问题：

1. 同时使用API​​网关和反向代理是否有意义（例如请求 - ＆gt; Api网关 - >反向代理（nginx） - ＆gt;具体的mictoservice）？在什么情况下？
2. 使用API​​网关可以实现的其他差异是什么，反向代理无法实现，反之亦然？

Answer 1

如果您意识到它们并非相互排斥，那么更容易思考它们。将API网关视为特定类型的反向代理实现。

关于您的问题，通常会将API网关视为位于反向代理后面的应用程序层以进行负载平衡和运行状况检查，这一点并不少见。一个例子就像是WAF三明治体系结构，因为你的Web应用程序防火墙/ API网关被反向代理层夹在中间，一个用于WAF本身，另一个用于与之交谈的各个微服务。

关于差异，它们非常相似。这只是命名法。当您采用基本的反向代理设置并开始抽取诸如身份验证，速率限制，动态配置更新和服务发现等更多部分时，人们更有可能将其称为API网关。

Answer 2

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

1. 只要此序列中的每个组件都能达到其目的，它就是有意义的。
2. 差异不在功能列表中，而是在应用配置更改的方式中。

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

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

希望它有所帮助。

Answer 3

API网关通常用作L7构造。

与纯反向代理相比，

API网关提供了其他功能。如果您考虑其中的某些门户网站，它们可以提供：

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

然而，随着Istio之类的服务网格的出现，Consul的许多API网关功能将被网格所包含。