负载均衡器和 API 网关混淆

Question

我一直致力于移动技术，现在我正在涉足后端系统，更具体地说是系统设计。我不断遇到关于 api 网关和负载均衡器角色的相互矛盾的陈述。谷歌搜索只返回了同样的六个结果，这些结果主要集中在一些著名服务提供的负载均衡器或 API 网关服务的实现上。我将在这里列出我面临的所有困惑，希望有人能够澄清所有这些。

有时，我发现 API 网关是与客户端设备通信的单点。另一方面，有些地方提到“请求发送到负载均衡器，负载均衡器将其均匀地分布在服务器上”。那么什么是正确的呢？API网关接收请求还是负载均衡器？

其他地方，当我用谷歌搜索这个主题时，说两者完全不同。我知道 API Gateway 可以做很多事情，比如 SSL 终止、日志记录、限制、验证等，但它也可以做负载平衡。那么API网关本身就是一个负载均衡器，还具备其他职责吗？

关于这个主题，我想了解负载均衡器是否在同一集群的服务器之间或不同的数据中心或集群之间分配负载？那么 API 网关呢？

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

可能很清楚，我完全困惑了。如果问题正确的话，在哪些系统中负载均衡器比 API Gateway 受益更多。

Answer 1

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

负载均衡器 -> 它是一个在协议或套接字级别（例如 tcp、http 或端口 3306 等）工作的软件。它的工作是通过将传入流量分配到具有各种逻辑的目的地（例如循环）来平衡传入流量。我不提供授权检查、请求身份验证等功能。

然而

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

关于解析域，DNS 很可能总是解析到负载均衡器，负载均衡器又从 API 网关服务获取响应。

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

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

Answer 2

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

但一般情况下，API Management 不包含负载均衡功能，因此需要与负载均衡器配合使用才能实现负载均衡功能。

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

基于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

Answer 3

这里需要考虑两种情况来澄清混乱。我已经使用微服务示例澄清了这一点，因为这只有在微服务中才有意义。

场景 1：您有一个 API 网关集群

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

场景 2：您有一个API 网关

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

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

在微服务环境中，您可能需要在多个地方使用负载均衡概念。就像接受外部网络一样，您将维护一个由AWS等云提供商提供的负载均衡器，如果有相同服务的多个实例注册到它，eureka（服务发现）也可以充当负载均衡器，最后我们还有客户端当您的微服务尝试在其中进行通信时，负载平衡（每个微服务都有自己的客户端负载平衡器来维护本地缓存），以避免每次都检查另一个微服务的地址，从而避免服务发现代理（eureka）的负担微服务。

注意：在流程图中，请不要混淆从 API Gateway --> Service Discovery --> 到微服务的路径，就好像网关将请求转发到 Service Discovery，稍后再将其转发。网关只是从发现代理检查服务注册表，然后将其路由到正确的微服务（不通过服务发现代理）

Answer 4

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

1. 我们可以为不同的后端系统配置不同的路由。
2. 我们获得负载平衡端点的静态 IP 地址（通常不适用于 API 网关）
3. 可以配置健康检查（通常不适用于API网关）

对于云提供商，通常“也为闲置付费”

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

但是，其主要目的是针对“ API 管理”。以下是“负载均衡器”中通常不可用的关键功能，

1. 可以实现速率限制、突发限制
2. 可以进行请求验证和请求/响应映射
3. 通常云API网关允许使用swagger规范导出/导入跨API平台
4. 允许缓存响应
   对于云提供商，通常是“按使用付费”