API网关与反向代理

如果你意识到它们并不相互排斥，那么考虑它们会更容易。 将API网关看作是特定类型的反向代理实现。

关于你的问题，看到这两者并用，API网关被视为一个位于反向代理之后的应用程序层，以进行负载平衡和运行状况检查，这并不罕见。 一个例子就像WAF三明治体系结构一样，Web应用程序防火墙/ API网关夹在反向代理层之间，一个用于WAF本身，另一个用于与其交谈的单个微服务。

关于差异，他们非常相似。 这只是命名。 当你进行一个基本的反向代理设置，并开始在认证，速率限制，动态配置更新和服务发现等更多部分上进行连接时，人们更可能称之为API网关。

我相信，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/

希望能帮助到你。

就个人而言，我经常发现API网关是一种反模式。

我通常会推荐采用反向代理优先的方法，并建议在每个服务上实现JWT认证，并在CDN端处理速率限制，虽然DDoS防护当然是昂贵的。

API网关是有好处的，当然也有一些你提到的。 我会添加这些：

• CON：紧密耦合 – 对于每个新端点，您必须实现API网关端点并部署2个服务
• CON：如果你在API网关端添加缓存，你可能会设置自己的各种奇怪的错误
• CON：你从开发者组织的角度（每个人都需要触及这个服务），从硬件/性能/可靠性的角度来看，都会造成一个瓶颈
• PRO：当你想要时，我发现网关最有用
  • 合并来自多个服务的数据
  • 重新格式化/简化数据/条带敏感数据等
  • 你使用多边形环境，并且对目标服务做任何上述改变都很笨拙 – 你基本上创建一个“视图模型”
  • 您确实想要针对API网关和核心服务控制缓存，即使它们都可以通过逆向代理进行访问

一般来说，我建议使用反向代理作为默认方法 – 这应该是半自动的 – 开发人员应该始终能够将任何服务标记为仅在群集内可访问。

另外，我建议仅在需要时才制作API网关，并根据业务领域接缝创建单独的网关。

另外，如果你还没有使用Kubernetes，那么你正在设法解决各种麻烦。