API网关与反向代理
为了处理微服务体系结构，它经常与反向代理（如nginx或apache httpd）一起使用，对于交叉关注点的实现，使用API网关模式。有时反向代理做API网关的工作。
看到这两种方法之间的明确区别将是很好的。使用API网关的潜在好处是调用多个微服务并聚合结果。API网关的所有其他职责都可以使用反向代理实现。例如：
- 身份验证（可以使用nginx LUA脚本完成）；
- 传输安全性。它本身反向代理任务；
- 负载平衡
- ...
- 同时使用API网关和反向代理是否有意义（如示例请求->API网关->反向代理(nginx)->具体微服务）？在什么情况下？
- 可以使用API网关实现而不能使用反向代理实现的其他区别是什么？
共有1个答案
如果你意识到它们并不是相互排斥的，那么就更容易思考它们。将API网关视为特定类型的反向代理实现。
关于您的问题，经常会看到两者结合使用，其中API网关被视为位于反向代理后面的应用层，用于负载平衡和健康检查。一个例子是类似WAF三明治体系结构的东西，其中Web应用程序防火墙/API网关被反向代理层夹在中间，一个层用于WAF本身，另一个层用于它与之对话的单个微服务。
关于不同之处，他们很相似。只是命名法。当您进行一个基本的反向代理设置并开始在更多的部分（如身份验证、速率限制、动态配置更新和服务发现）上进行连接时，人们更有可能将其称为API网关。
-
null 我倾向于认为它是第一个，但在这种情况下，nginx不会是应用程序的入口...（这是个问题吗？）
-
我使用Nginx作为反向代理，它接收请求，然后执行proxy_pass以从运行在8001端口上的上游服务器获得实际的web应用程序。 如果我转到mywebsite.com或执行wget，我会在60秒后获得504网关超时...但是，如果我加载mywebsite.com:8001，应用程序将按预期加载！ 和Nginx错误日志的输出：
-
我为我的应用程序创建了一个API网关，它将充当其他微服务的前端控制器。在我的生产设置中，我使用Nginx作为网关的反向代理 API网关在端口8080上运行 Nginx配置如下： gateway-api.conf： nginx中的超时设置。形态： Spring云网关gradle文件： 网关应用程序： 问题陈述： 在我的一个微服务中，一个REST API需要3分钟以上才能完成。如果我通过调用这个API
-
我目前正在尝试为客户端界面-服务器交互构建一个API。我已经决定使用ASP.NET核心作为API，Nginx作为托管平台(在Ubuntu 18.04上)。由于ASP.NET使用Kestrel，我们设置了一个反向代理，将请求从Nginx转发到Kestrel——也就是托管API的服务器。我们在NGINX服务器上设置了SSL，但是它没有在Kestrel服务器上设置。 简单地说，我不知道如何在 Kestr
-
本文向大家介绍nginx正向代理与反向代理详解，包括了nginx正向代理与反向代理详解的使用技巧和注意事项，需要的朋友参考一下 正向代理 就是假设有一个内网 内网有两台机器，这两台机器只有 a 可以上网 b 不能上网，但是 a 和 b 通过网络相连接 这时如果 b 想访问外网，就可以通过 a 来正向代理访问外网 正向代理就是在内网中模拟目标服务器，把内网中其它机器的请求 转发给外网中的真正的目标服
-
我知道正向代理和反向代理的区别，但不清楚反向代理与网关的区别。