问负载均衡器和API网关混淆

EN

API网关主要用于API管理，并提供各种其他关键功能，如标识和访问管理( IAM )、速率限制、断路器。因此，它主要消除了为每个微服务实现诸如安全性、缓存、节流和监视等功能的API特定代码的需要。Microservices通常在API网关的帮助下公开用于前端、其他微服务和第三方应用的其他API。

但是，通常情况下，API管理不包括负载平衡功能，因此它应该与负载均衡器一起使用来实现相同的功能。

在基于Azure的系统体系结构中，有一个Azure应用网关(Azure Application Gateway )，它是一个运行在第7层上的负载均衡器，它提供了比传统负载均衡器(第4层)更多的基于HTTP请求或流量内容的附加属性的路由选择功能。这也可以被称为应用负载均衡器。它将与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

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

负载均衡器->，它是一个在协议或套接字级别工作的软件(例如。( tcp、http或端口3306等)它的工作是平衡传入的流量，将其分配到具有各种逻辑的目的地(例如。圆形知更鸟)。我不提供诸如授权检查、请求认证等功能。

鉴于

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

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

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

希望我能解释并澄清你的困惑。

这里有两种情况需要考虑，以澄清混淆。我已经用微服务的例子澄清了这一点，因为这只有在那里才有意义。

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

用户-->负载均衡器(由云提供商提供，如AWS或您自己提供)

场景2:您有一个单API网关

用户-> API网关-服务发现代理(像尤里卡一样)

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

在微服务环境中，您可能需要在多个地方使用负载平衡概念。要接受外部网络，您将维护云提供商(如AWS )提供的负载均衡器，如果有多个相同服务的实例被注册在其中，eureka (服务发现)也会起到负载平衡器的作用，最后，当您的微服务试图通过不每次检查其他微服务的地址来避免对服务发现代理(Eureka)(Eureka)进行通信时，客户端负载平衡(每个微服务都有自己的客户端负载均衡器，保持本地缓存)。

注意:在流程图中，请不要混淆从API网关-->服务发现--到Microservice的路径，就好像网关将请求转发到稍后路由它的服务发现。网关只是从发现代理中检查服务注册中心，然后将其路由到正确的微服务(而不是通过服务发现代理)。