API网关到服务均衡器的粒度

Question

开放源码软件API网关通常与内置负载平衡功能捆绑在一起.我们在Netflix Zuul和Kong身上看到了这个。

在面向服务的体系结构中，许多微服务正在与许多其他服务进行交谈，在这种体系结构中，每个服务都有自己的API网关，有自己的负载均衡器，可以为该服务的所有节点提供流量服务吗？还是有一个单一的网关路由流量，为其背后的每个服务负载平衡器的典型吗？如果是后者，那么为什么开放源码软件网关通常具有作为一流公民的负载平衡功能？

例如，假设后端由3个web服务组成:订单、支付和发货：

• 订单跟踪目录(可订购)项目，并接收客户端应用程序的订单。
• 当订单WS收到订单请求时，它会与付款WS联系以处理付款。
• 在付款返回成功的回复后(付款成功)，订单WS向船运WS发出订单，以处理仓库/包装/运输物流

是否有典型的：

1. 客户端应用程序调用的单个API网关，然后将订单请求路由到订购WS的负载均衡器(例如，在https://orders.example.com上)，后者依次向一个订单WS实例提供流量服务(启动订单处理流程)；或.
2. 每个服务都有一个API网关？客户端应用程序调用订单WS的网关/均衡器，后者将流量转发给订单WS实例，后者调用支付WS的网关/均衡器，后者将流量转发给支付WS实例，等等。

我当时的印象是前一种情况，但Zuul和Kong的主要特点是广告负载平衡，这让我失望了。有什么想法吗？

Answer 1

没有什么可以阻止所有服务都使用单个API网关实例，同时仍然管理服务间通信。每个单独的服务只需通过中央API网关将所有请求发送到其他服务。例如，下面的序列图演示了通过order webservice示例的网络路径：

为了获得API网关的好处，所有到服务的通信--服务间和外部--必须通过网关(或网关)进行。网关作为一种中间件增加了价值，包括请求跟踪、外科路由等功能。如果请求直接发送到底层服务，则网关的可观察性和功能将完全丢失。

负载平衡实际上不会改变这里的任何事情。在单一API网关模型中，通过网关对服务的请求分布在服务的所有后端服务器之间。实际上，如果网关根本不存在，那么网关执行的负载平衡看起来就像一个基于DNS循环的负载均衡器。然而，与简单的DNS-RR负载平衡相比，网关可以提供更多的智能负载平衡(监视服务服务器运行状况等)。

尽管如此，Netflix在内部为每个服务运行一个Zuul实例。看看他们的架构：

资料来源:我们如何在Netflix使用Zuul。

这仍然维护了API网关的许多好处，但是它有一个明显的问题--将服务发现的问题传递给服务使用者(其他服务和/或客户端)：

在单个API网关的情况下，网关可以在著名的IP地址或DNS名称下到达，并且可以在其中进行所有服务发现。这意味着调用某些服务的代码只需要该服务的名称和单个网关的著名地址。

但是，对于每个服务都有一个网关，调用某些服务的代码将需要知道该服务的API网关的地址。这将需要一个外部服务发现系统，也许类似于Netflix's Eureka。

希望这能有所帮助！我花了很多时间研究这个问题，所以我对这个信息很有信心。