为了处理微服务架构，它通常与反向代理(例如 nginx 或 apache httpd)一起使用，并用于横切关注点实现 API gateway pattern is used 。有时反向代理会完成 API 网关的工作。
很高兴看到这两种方法之间的明显差异。 看起来使用 API 网关的潜在好处是调用多个微服务并聚合结果。所有其他responsibilities API网关可以使用反向代理来实现。如:
- 身份验证(可以使用 nginx LUA 脚本完成)；
- 交通安全。它本身是反向代理任务；
- 负载平衡
- ...
基于此，有几个问题:
- 同时使用 API 网关和反向代理是否有意义(例如请求 -> API 网关 -> 反向代理(nginx) -> 具体微服务)？什么情况下？
- 可以使用 API 网关实现而不能通过反向代理实现(反之亦然)还有哪些其他区别？
最佳答案
如果您意识到它们并不相互排斥，那么思考它们就会更容易。将 API 网关视为特定类型的反向代理实现。
关于您的问题，两者结合使用的情况并不少见，其中 API 网关被视为位于反向代理后面用于负载平衡和运行状况检查的应用程序层。一个示例是类似于 WAF 三明治架构，其中您的 Web 应用程序防火墙/API 网关被反向代理层夹在中间，一个用于 WAF 本身，另一个用于它与之通信的各个微服务。
关于差异，它们非常相似。这只是命名法。当您进行基本的反向代理设置并开始附加更多功能(例如身份验证、速率限制、动态配置更新和服务发现)时，人们更有可能将其称为 API 网关。
关于nginx - API网关与反向代理，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/35756663/