我一直致力于移动技术，现在我正在进入后端系统，更具体地说是系统设计。我不断遇到关于 api 网关和负载均衡器角色的矛盾陈述。谷歌搜索只返回了同样的六个结果，主要集中在一些著名服务提供的负载均衡器或 api 网关服务的实现上。我将在这里列出我面临的所有困惑，希望有人能澄清所有这些。
有时,我遇到 API Gateway 是与客户端设备通信的单点。另一方面,有些地方提到 'request goes to load balancer,它在服务器上平均分配'。那么什么是正确的?API Gateway 接收请求或负载均衡器?
其他地方,当我搜索主题时,说两者完全不同。我已经了解 API Gateway 做了很多东西,如 SSL 终止,日志记录,节流,验证等,但它也做负载均衡。所以 API Gateway 本身就是一个负载均衡器,配备了其他职责?
关于这个主题，我想了解负载均衡器是在同一集群的服务器之间还是在不同的数据中心或集群之间分配负载？
什么是如此具体的 api 网关,它是微服务架构的默认选择?API 网关托管在哪里?DNS 将域名解析为负载均衡器或 api 网关?
如果问题是正确的，那么在什么系统中，负载均衡器比 API Gateway 受益更多。
20
API 网关和负载均衡器是两个不同的东西。
负载平衡器-它是一种在协议或套接字级别（例如 tcp，http 或端口 3306 等）工作的软件。它的工作是通过使用各种逻辑（例如轮询）将传入的流量分配到目的地来平衡传入的流量。我不提供授权检查，请求身份验证等功能。
鉴于
API Gateway-它是由各种托管公司提供的托管服务，用于管理 API 操作以无缝扩展 API 基础设施。它负责访问控制，响应缓存，响应类型，授权，身份验证，请求限制，数据处理，根据自定义规则识别正确的目的地以及无缝扩展后端。通常，托管 API 网关默认情况下具有可扩展的基础设施，因此将它们放在负载均衡器后面可能没有意义。
关于解析域，很可能总是 DNS 解析到负载均衡器，负载均衡器又从 API 网关服务获取响应。
DNS-& gt;负载均衡器-& gt;API 网关-& gt;后端服务
希望我能解释和澄清你的困惑。
10
API 网关主要进行 API 管理，并提供各种其他关键功能，例如 IAM（身份和访问管理），速率限制，断路器。因此，它主要消除了为每个微服务实现安全性，缓存，节流和监视等功能的 API 特定代码的需要。微服务通常会在 API 网关的帮助下公开 REST API，以供前端，其他微服务和第三方应用程序使用。
但是，通常情况下，API 管理不包括负载平衡功能，因此应将其与负载平衡器结合使用以实现相同的功能。
在基于 Azure 的系统体系结构中，有 Azure 应用程序网关，它是一个负载平衡器，在第 7 层上运行，并提供比传统负载平衡器 (第 4 层) 更多的功能，在路由流量方面使用基于 HTTP 请求或流量内容的附加属性的路由决策。这也可以称为应用程序负载平衡器。它应与 Azure API 管理应用程序 (网关 API) 一起使用。Azure 有一个流量管理器，用于在 DNS 级别运行，它使用 DNS 将客户端请求定向
基于 Azure 的系统概述：
这里有几个相关的参考：
Azure 应用程序网关-https://learn.microsoft.com/en-us/azure/application-gateway/application-gateway-introduction
Azure 负载平衡器-https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-overview
Azure 流量管理器-https://learn.microsoft.com/en-us/azure/traffic-manager/traffic-manager-overview
场景架构-https://learn.microsoft.com/en-us/azure/traffic-manager/traffic-manager-load-balancing-azure
4
这里有两种情况需要考虑来澄清混淆。我已经使用微服务示例澄清了这一点，因为这只有在那里才有意义。
场景 1：您有一个 API 网关集群
用户---负载均衡器（由 AWS 或您自己的云提供商提供）---& gt;API 网关集群---& gt;服务发现（如eureka）---& gt;微服务 A---& gt;客户端负载均衡器---& gt;微服务 B
场景 2：您有一个单一 API 网关
用户---& gt;API 网关---& gt;服务发现（如Eureka）---& gt;微服务 A---& gt;客户端负载均衡器-& gt;微服务 B
我希望你明白为什么我们在场景 1 中的 API 网关之前需要负载均衡器，因为我们有多个 API 网关实例来处理大流量并避免单个 api 网关的负担，因为网关本身可以有几个tasks根据要求进行管理，以便在它们之间分配负载，我们有负载均衡器。
在微服务环境中，您可能需要在多个地方进行负载平衡概念。就像接受外部网络一样，您将维护由 AWS 等云提供商提供的负载平衡器，如果向其注册了同一服务的多个实例，则 eureka（Service Discovery）也像负载平衡器一样，最后我们还具有客户端负载平衡（每个微服务都有自己的客户端负载平衡器，用于维护本地缓存），当您的微服务尝试与其他服务进行通信时，
注意：在流程图中，请不要混淆从 API Gateway--& gt;Service Discovery--& gt;到微服务的路径，就好像网关正在将请求转发到 Service Discovery，该请求稍后会将其转发。网关只是从 Discovery 检查服务注册表，然后将其路由到正确的微服务（而不是通过 Service Discovery ）
3
负载平衡器：其主要目的是通过负载平衡多个后端系统之间的流量来进行分配。
我们可以为不同的后端系统配置不同的路由。
我们获得负载平衡端点的静态 IP地址（通常不提供与 API 网关）
可以配置运行状况检查（通常不适用于 API 网关）
对于云提供商，通常“同时支付闲置费用”
API 网关：这也将流量路由到基于 URL 的后端系统
但是，其主要目的是针对“API 管理”。以下是通常不在“负载均衡器”中可用的关键功能，
可以实现速率限制、突发限制
可以做请求验证和请求 / 响应映射
通常，云 API 网关允许使用 swagger 规范导出 / 导入跨 API 平台
允许缓存响应
对于云提供商，通常为“按使用付费”
本站系公益性非盈利分享网址，本文来自用户投稿，不代表码文网立场，如若转载，请注明出处
评论列表（61条）