我读了有关API网关模式的文章。我意识到API网关通常用作反向代理，但这会造成瓶颈的情况。如果对应用程序公共服务的所有请求都通过单个网关，或者甚至在网关的多个副本上进行单个加载平衡器(也许是可以比API网关更容易处理大量带宽的硬件负载平衡器(，那么访问点是瓶颈。
我也知道这是一个宽阔的瓶颈，因为它只需要传递代理的消息，因为门户和负载平衡器本身对任何处理或查询概不负责。但是，想象与许多用户的一个非常大的应用程序，人们需要非常强大的硬件，以免注意到通道或负载平衡器上的大量带宽，因为该网关向网关揭示的每个微服务的每个请求都通过该单个接入点传播。<<<<<<<<<<<<<<<<<<<<
如果API网关而不是将客户端重定向到公开曝光的微服务(有点像自定义DNS查找(，则硬件要求将要低得多。这是因为往返于API网关的消息很小，仅由微服务名称组成的请求，仅由关联的公共IP地址组成的响应。
我认识到，由于外部请求的增加，这种模式将涉及更大的延迟。由于每个微服务都是公开曝光的，而不是在单个入口点提供身份验证，因此也将更加困难。但是，它可以使带宽更加均匀地分布，并提供更宽的瓶颈，从而使应用程序更具扩展性。这是有效的策略吗？
从许多角度来看，基于DNS/公共IP的方法不好：
- 较高的攻击表面积，因为您有太多的暴露点，并且每个都需要受到保护
- 不。所需的公共IPS是更高的
- 您可能需要更多带有子域或域的DNS设置才能为这些API
- 很多次您的API会在根路径上运行，但您可能需要将它们暴露在文件夹路径
example.com/service1上，这需要您要使用一些网关进行相同的网关 - 处理这些公共暴露的SSL证书
- 在一组集中的节点与确保每个公开暴露服务的节点的安全性成为一项非常困难的任务
虽然可以将客户直接重定向到节点时，但有一些陷阱。
安全性，证书和DNS管理已由@tarun覆盖
高可用性的问题
dns的缓存域与IP的域，它们的服务相当积极，因为这些很少发生变化。如果我们使用DNS公开公开曝光多个服务实例，并且其中一台服务器会降低，或者我们正在部署，DNS将继续将请求路由到节点上，这些节点会降低了相当长的时间。我们无法控制外部DNS及其政策。使用反向代理，我们避免根据健康检查击中这些节点。