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

我读过关于API网关模式的文章。我意识到API网关通常充当反向代理，但这会造成瓶颈情况。如果对应用程序公共服务的所有请求都通过单个网关，甚至通过网关多个副本的单个负载平衡器（可能是硬件负载平衡器，它比API网关更容易处理大量带宽），那么单个接入点就是瓶颈

我也知道这是一个很大的瓶颈，因为它只需要在代理中传递消息，因为网关和负载平衡器本身不负责任何处理或查询。然而，想象一个拥有许多用户的非常大的应用程序，需要非常强大的硬件才能不注意网关或负载平衡器上传输的巨大带宽，因为网关向每个微服务发出的每个请求都会通过单个接入点传输

如果API网关将客户端重定向到公开的微服务（有点像自定义DNS查找），那么硬件要求就会低得多。这是因为进出API网关的消息非常小，请求只包含一个微服务名称，响应只包含相关的公共IP地址

---

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

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

• 更高的攻击表面积，因为你有太多的暴露点，每个都需要保护
• 需要的公共IP数量更高
• 对于这些API，您可能需要更多具有子域或域的DNS设置
• 很多时候，您的API将在根路径上运行，但您可能希望在文件夹路径

  example.com/service1

  上公开它们，这需要 您需要使用一些网关来实现相同的功能
• 处理这些公开暴露的SSL证书
• 集中的一组节点上的安全性与保护每个公开的服务的安全性成为一项非常困难的任务

---

虽然理论上可以将客户端直接重定向到节点，但也存在一些缺陷

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

高可用性问题

DNS对其服务的域和IP进行了相当积极的缓存，因为这些域很少发生变化。如果我们使用DNS公开多个服务实例，并且其中一个服务器停机，或者如果我们正在进行部署，DNS将继续将请求路由到停机时间相当长的节点。我们无法控制外部DNS及其策略。

---

使用反向代理，我们可以避免基于运行状况检查而命中这些节点。

这些原因中的许多基本相同；1、5和6都指保护多个节点，而不是单个入口点。4真的不是什么大问题；URL无论如何都不应该用于任何面临UX问题的客户，因此，如果它们都必须是子域而不是单个域的不同端点，那么如果这意味着应用程序更具可伸缩性，那么就可以了。如果它是一个支持云的系统，那么Bullet 2就不是什么大问题；这些IP是随平台提供的。子弹3也很容易克服。因此，如果它们都可以使用通配符SSL进行保护，那么问题出在哪里？另外，如果网关将客户端重定向到正确的子域，例如example.com/gateway/microservice1转到microservice1.example.com，那么客户端甚至都不关心子域。无论如何，他们通过“文件夹结构”的重定向来访问子域。@nerdizle，有多种方法可以做事情，然后通常有一种更被接受的方法来做事情。入口通道通常是这样一种被接受的方式。网关与直接曝光的额外跳数可能会给你额外的毫秒，但你必须权衡代价。此外，如果您使用的是响应时间非常关键的应用程序，那么您可能会研究这些类型的解决方案，但如果不这样做，则会造成过度消耗。您仍然可以为每个微服务使用反向代理，但可以使用从网关到这些反向代理的重定向。那么，只有当反向代理失效时，这才是一个问题。如果是这样的话，没有任何策略可以解决这个问题。如果无法访问microservice负载平衡器，则无法访问microservice。您只需要为每个负载平衡器/反向代理提供公共IP/DNS解析，它们无论如何都不应该更改。同意。但随后，您会遇到您最初提到的相同瓶颈，尽管是在稍后的阶段。此外，为了进行金丝雀部署等，您可能希望在同一反向代理后面捆绑一些服务。此分组很快升级为原始问题，我们无论如何都需要解决。如果您的服务组彼此完全独立，并且从不需要相互交互，那么请务必将它们完全分区，并通过重定向导航到它们。这是公平的。虽然问题“对微服务的每个请求都在反向代理上受到瓶颈限制”，但其影响远小于“对整个应用程序的每个请求都在反向代理上受到瓶颈限制”，但无论如何，您都会在反向代理上遇到瓶颈，只有公开每个节点，才能防止出现瓶颈。