重定向是API网关的有效策略吗？

Question

我阅读了this article有关API网关模式的信息。我意识到API网关通常充当反向代理，但这会造成瓶颈。如果对应用程序公共服务的所有请求都通过单个网关，或者甚至跨越一个网关的多个副本的单个负载均衡器（也许是一个硬件负载均衡器，可以比API网关更轻松地处理大量带宽），则该单个负载均衡器访问点是瓶颈。

我还理解这是一个很大的瓶颈，因为网关和负载平衡器本身不负责任何处理或查询，因此它只需要在代理中传递消息即可。但是，考虑到一个拥有许多用户的超大型应用程序，鉴于对网关公开的每个微服务的每个请求都通过该单个访问点进行传输，因此将需要功能非常强大的硬件以不注意到在网关或负载平衡器上传播的大量带宽。 / p>

如果API网关只是简单地将客户端重定向到公开显示的微服务（有点像自定义DNS查找），则硬件要求会低得多。这是因为往返于API网关的消息非常小，请求仅包含微服务名称，而响应仅包含关联的公共IP地址。

我认识到，由于外部请求的增加，此模式将涉及更长的延迟。由于每个微服务都是公开公开的，而不是在单个入口点提供身份验证，因此保护起来也将更加困难。但是，这将允许带宽更均匀地分配，并提供更大的瓶颈，从而使应用程序具有更大的可伸缩性。这是有效的策略吗？

Answer 1

从很多角度来看，基于DNS /公共IP的方法都不好：

• 更高的攻击表面积，因为暴露点太多，每个都需要保护
• 不。所需的公共IP数量较高
• 对于这些API，您可能需要具有子域或域的更多DNS设置
• 很多时候，您的API会在根路径上运行，但是您可能希望将它们公开在文件夹路径example.com/service1上，这需要 您可以将某些网关用于同一目的
• 处理这些公开曝光的SSL证书
• 针对重点节点集的安全与确保每个公开的服务的安全成为一项艰巨的任务

Answer 2

从理论上讲，可以将客户端直接重定向到节点，但是有一些陷阱。

@Tarun已涵盖安全性，证书和DNS管理

问题具有高可用性

DNS缓存的域和IP相当激进，因为它们很少更改。如果我们使用DNS公开地公开服务的多个实例，而其中一台服务器出现故障，或者如果我们正在进行部署，则DNS会继续将请求路由到发生故障的节点上相当长的时间。我们无法控制外部DNS及其策略。 使用反向代理，可以避免基于运行状况检查击中那些节点。