负载均衡器和API网关混淆

Question

负载均衡器和API网关混淆

dnsload-balancingdistributed-systemapi-gatewaysystem-design

51

我一直从事移动技术的工作，现在我正在涉足后端系统，更具体地说是系统设计。我经常遇到有关API网关和负载均衡器角色的冲突说法。在谷歌搜索中，我只找到了大同小异的几个结果，主要集中在某些著名服务提供商提供的负载均衡器或API网关服务的实现上。我将在此列出我所面临的所有困惑，希望有人能澄清其中的所有问题。

有时，我会看到API Gateway是与客户端设备进行通信的唯一点。另一方面，有些地方提到“请求发送到负载均衡器，它将其平均分配给服务器”。那么什么是正确的？API Gateway接收请求还是负载均衡器？

其他一些地方在我谷歌搜索这个主题时说，这两个东西完全不同。我已经理解了API Gateway所做的很多工作，比如SSL终止、日志记录、限制流量、验证等，但它也可以进行负载均衡。因此，API Gateway本身就是一个负载均衡器，同时拥有其他职责吗？

关于这个话题，我想了解负载均衡器是将负载分配给同一集群中的服务器还是跨不同数据中心或集群？API Gateway呢？

API网关有什么特别之处，以至于它成为微服务架构的默认选择？API网关托管在哪里？DNS将域名解析为负载均衡器或API网关？

很明显，我完全困惑了。如果问题正确的话，在哪些系统中负载均衡器比API网关更有优势。

- Farhan

6个回答

13

API网关主要进行API管理，并提供各种其他重要功能，如IAM（身份和访问管理），速率限制，断路器。因此，它主要消除了为每个微服务实现API特定代码的需要，例如安全性、缓存、节流和监视功能。微服务通常使用API网关公开REST API，以帮助前端、其他微服务和第三方应用程序。

然而，通常，API管理不包括负载平衡功能，因此应与负载均衡器一起使用以实现相同的功能。

在基于Azure的系统架构中，有一个名为Azure Application Gateway的负载均衡器，它在第7层运行，并提供比传统负载均衡器（第4层）更多的功能，以便使用HTTP请求的附加属性或流量内容进行路由决策来路由流量。这也可以称为应用程序负载均衡器。它应与Azure API Management（API网关）一起使用。Azure还具有Traffic Manager，可在DNS级别上操作，该管理器使用DNS根据流量路由方法和端点的健康状况将客户端请求定向到最合适的服务端点。Traffic Manager还使用在DNS级别配置的规则，并启用在多个区域和数据中心之间分配负载。在每个区域或数据中心内，应有与负载均衡器配对的应用程序网关，以便应用程序网关帮助确定要从哪个应用程序服务器获取响应，而负载均衡器则帮助在负载平衡方面。

基于Azure的系统概述:

System overview based on Azure

以下是相关参考资料：

1. Azure应用程序网关 - https://learn.microsoft.com/en-us/azure/application-gateway/application-gateway-introduction 2. Azure负载均衡器 - https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-overview 3. Azure流量管理器 - https://learn.microsoft.com/en-us/azure/traffic-manager/traffic-manager-overview 4. 情景架构 - https://learn.microsoft.com/en-us/azure/traffic-manager/traffic-manager-load-balancing-azure

- Karthik Balaguru

4

这里API网关在哪里？ - toto'

10

这里有两种情况需要考虑以澄清混乱。我使用微服务示例进行了说明，因为只有在那里才有意义。

情况1：您拥有API网关群集

用户--->负载均衡器（由AWS等云提供商或您自己提供）---> API网关群集 ---> 服务发现代理（如eureka）---> 微服务A ---> 客户端负载均衡器 ---> 微服务B

情况2：您只有一个API网关

用户---> API网关 ---> 服务发现代理（如Eureka）---> 微服务A ---> 客户端负载均衡器 ---> 微服务B

我希望您能理解为什么在情况1中我们需要在API网关之前使用负载均衡器，因为我们有多个API网关实例来处理大量流量，并避免单个API网关的负担，因为网关本身可以有几个tasks根据要求进行管理，因此为了在它们之间分配负载，我们需要负载均衡器。

在微服务环境中，您可能需要在多个位置使用负载均衡概念。例如，为了接受外部网络，您将维护由云提供商（如AWS）提供的负载均衡器，eureka（服务发现）也像负载均衡器一样运作，如果有多个相同服务的实例在其中注册，最后我们还有客户端负载均衡（每个微服务都有自己的客户端负载均衡器，维护本地缓存），当您的微服务试图相互通信时，只是为了避免对服务发现代理（eureka）造成负担，不需要每次都检查其他微服务的地址。

注：在流程图中，请不要将API网关->服务发现->微服务的路径误解为网关将请求转发到稍后路由它的服务发现。网关只是从发现代理检查服务注册表，然后将其路由到正确的微服务（而不是通过服务发现代理）。

- HumbleBee

场景1很好地解释了在API网关集群之前加载负载均衡器的必要性 :) - exexzian

5

负载均衡器：其主要目的是通过负载均衡来分配流量到多个后端系统。

我们可以为不同的后端系统配置不同的路由。
我们可以得到负载均衡端点的静态IP地址（通常在API网关中不可用）。
可以配置健康检查（通常在API网关中不可用）。

在云服务提供商的情况下，通常会“按闲置时间付费”。

API网关：这也是根据URL将流量路由到后端系统。

但是，它的主要目的是针对“API管理”。以下是通常在“负载均衡器”中没有的关键功能：

可以实现速率限制、瞬时限制。
可以进行请求验证和请求/响应映射。
通常云API网关允许使用swagger规范导入/导出跨API平台。
可以缓存响应。
在云服务提供商的情况下，通常会“按使用量付费”。

- sridhar

1

DNS负责将请求路由到给定域名内最近的IP地址。

API网关负责身份验证，查找正确的API（带或不带负载均衡器）进行调用和断路器，响应合并。

负载均衡器负责根据负载或轮询方式将传入请求分配到具有相同服务部署的不同机器上。

因此，一种方法是 DNS到网关到LB

注意：根据流量和用例，LB可以放置在网关之前。

- user3285553

1

API网关是一个反向代理，位于客户端和一组后端服务之间，允许客户端使用单个集中的入口点访问这些后端服务。

因此，在使用微服务架构实现应用程序时，最常使用API网关。

API网关接受所有后端服务的应用程序编程接口（API）调用，将各种后端服务用于处理请求（甚至将一个客户端请求拆分为多个内部请求），合并/聚合结果，并将单个响应返回给客户端。

后端服务可以部署在各种平台上，例如无服务器、基于云的服务、本地等。

与API网关相对的选择是让负载均衡器分别位于每个后端服务之前。这可能会使客户端与您的API集成更加复杂，因为他们可能需要进行多次请求，甚至可能使用不同的协议来实现一个目标。通过提供API网关，您的客户端可以使用单个请求和单个安全协议发送请求-协调不同后端服务之间的工作并转换为正确的协议的责任由API网关承担。

使用API网关可以帮助您管理和监控跨多个服务的事物，例如访问控制（身份验证、授权）、速率限制/节流、SSL/TLS终止、分析、监控、计费、管理维护计划、缓存响应、基于规则的路由等等。

负载均衡器是一种软件或硬件设备，用于进行负载均衡，其目标是防止任何一个后端/源服务器过载。

大多数云服务提供商不需要在API网关前面使用负载均衡器，因为云服务提供商有责任扩展支持API网关的资源。

API可能会将请求路由到负载均衡器，而不是直接发送给服务，负载均衡器会将负载均匀地分配给多个服务实例。

- d4nyll

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- mdeora · Accepted Answer

API网关和负载均衡器是两个不同的东西。

负载均衡器 -> 它是一种工作在协议或套接字层面（例如tcp，http或端口3306等）的软件。它的任务是通过各种逻辑（例如轮询）将传入的流量平衡分配到目的地。它不提供授权检查，请求认证等功能。

而

API网关 -> 它是由各种托管公司提供的托管服务，用于管理API操作以无缝扩展API基础架构。它负责访问控制、响应缓存、响应类型、授权、身份验证、请求限制、数据处理、根据自定义规则识别正确的目的地，并无缝扩展后端。通常，托管的API网关默认带有可扩展的基础架构，因此将它们放在负载均衡器后面可能没有意义。

关于解析域名，最有可能的情况是DNS总是解析到负载均衡器，然后从API网关服务获取响应。

DNS -> 负载均衡器 -> API网关 -> 后端服务

希望我能解释清楚并消除您的困惑。