负载平衡器和 API 网关混乱
Load balancer and API Gateway confusion
我一直从事移动技术方面的工作，现在我正在涉足后端系统，更具体地说是系统设计。对于 api 网关和负载均衡器的角色，我不断遇到相互矛盾的说法。谷歌搜索只返回了相同的六个结果，这些结果主要集中在一些著名服务提供的负载均衡器或 api 网关服务的实现上。我会在这里列出我面临的所有困惑，希望有人能澄清所有这些问题。
有时，我发现 API 网关是与客户端设备的单点通信。另一方面，有些地方提到'request goes to load balancer, which spreads it across servers equally'。那么什么是正确的呢？ API 网关接收请求或负载均衡器？
其他地方，我google了题目，说两者完全不同。我知道 API 网关做了很多事情，比如 SSL 终止、日志记录、节流、验证等，但它也做负载平衡。那么API网关本身就是一个负载均衡器，还配备了其他职责？
关于这个话题，我想了解负载均衡器是在同一集群的服务器之间分配负载还是跨不同的数据中心或集群？ API 网关呢？
api 网关有什么特别之处，以至于它是微服务架构的默认选择？ API 网关托管在哪里？ DNS 将域名解析为负载平衡器或 api 网关？
很明显，我完全糊涂了。如果问题正确，负载均衡器在哪些系统中比 API 网关更受益。
API 网关和负载均衡器是两个不同的东西。
Load Balancer -> 它是一种在协议或套接字级别（例如 tcp、http 或端口 3306 等）工作的软件。它的工作是通过将传入流量分配到具有各种逻辑的目的地来平衡传入流量（例如循环法）。
我不提供授权检查、请求身份验证等功能
鉴于
API 网关 -> 它是各种托管公司提供的托管服务，用于管理 API 操作以无缝扩展 API 基础设施。
它负责访问控制、响应缓存、响应类型、授权、身份验证、请求限制、数据处理、根据自定义规则识别正确的目的地以及无缝扩展后端。
Generally Managed API 网关默认带有可扩展的基础设施，因此将它们放在负载均衡器后面可能没有意义。
关于解析域，很可能总是 DNS 解析到负载均衡器，而负载均衡器又从 API 网关服务获取响应。
DNS -> Load Balancer -> API gateway -> Backend service
希望我能解释清楚你的困惑。
API 网关主要进行 API 管理并提供各种其他关键功能，例如 IAM（身份和访问管理）、速率限制、断路器。因此，它主要消除了为每个微服务实现安全、缓存、节流和监控等功能的 API 特定代码的需要。微服务通常在 API 网关的帮助下公开 REST API 用于前端、其他微服务和第三方应用程序。
但是，一般情况下，API管理不包含负载均衡功能，所以需要配合负载均衡器来实现。
在基于 Azure 的系统架构中，有 Azure Application Gateway，它是一个运行在第 7 层的负载均衡器，在使用基于附加信息的路由决策来路由流量方面提供了比传统负载均衡器（第 4 层）更多的功能HTTP 请求的属性或流量的内容。这也可以称为应用程序负载平衡器。它应与 Azure API 管理（API 网关）结合使用。 Azure 有一个在 DNS 级别运行的流量管理器，它使用 DNS 根据流量路由方法和端点的健康状况将客户端请求定向到最合适的服务端点。流量管理器还使用在 DNS 级别配置的规则，并支持将负载分布到多个区域和数据中心。在每个区域或数据中心内，应有应用网关与负载均衡器耦合，应用网关应帮助确定从中获取响应的应用服务器，负载均衡器应帮助负载均衡。
基于 Azure 的系统概述：
以下是一些相关的参考资料：
Azure 应用程序网关 - https://docs.microsoft.com/en-us/azure/application-gateway/application-gateway-introduction
Azure 负载均衡器- https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-overview
Azure 流量管理器 - https://docs.microsoft.com/en-us/azure/traffic-manager/traffic-manager-overview
场景架构-https://docs.microsoft.com/en-us/azure/traffic-manager/traffic-manager-load-balancing-azure
负载均衡器：
它的主要目的是在多个后端系统之间通过负载均衡分配流量。
- 我们可以为不同的后端系统配置不同的路由。
- 我们为负载平衡端点获取静态 IP 地址（通常不适用于 API 网关）
- 可以配置健康检查（通常不适用于 API 网关）
如果是云提供商，通常“还要为闲置付费”
API 网关 :
这也将流量路由到基于 URL
的后端系统
BUT，其主要目的是针对“API管理”。
以下是“负载均衡器”通常不提供的关键功能，
- 可以实现速率限制，突发限制
- 可以进行请求验证和request/response映射
- 通常云 API 网关允许使用 swagger 规范 export/import 跨 API 平台
- 允许缓存响应
对于云提供商，通常是“按使用付费”
这里有两种情况需要考虑以澄清混淆。我已经使用微服务示例对此进行了澄清，因为这仅在那里才有意义。
场景 1：您有一个 API 网关集群
用户 ---> 负载均衡器（由 AWS 等云提供商或您自己提供）---> API 网关集群 ---> 服务发现代理（如 eureka) ---> 微服务 A ---> 客户端负载均衡器 ---> 微服务 B
场景 2：您有一个 单个 API 网关
用户 ---> API 网关 ---> 服务发现代理（如 Eureka）---> 微服务 A ---> 客户端负载平衡器 -> 微服务 B
我希望你明白为什么我们在场景 1 中的 API 网关之前需要负载均衡器，因为我们有多个 API 网关实例也可以处理大流量并避免负担在单个 api 网关上，因为网关本身可以根据需要管理多个 tasks，所以为了在它们之间分配负载，我们有负载平衡器。
在微服务环境中，您可能需要在多个地方使用负载均衡概念。喜欢接受外部网络，您将维护由 AWS 等云提供商提供的负载均衡器，eureka（服务发现）如果注册了相同服务的多个实例，也可以充当负载均衡器，最后我们还有客户端负载平衡（每个微服务都有自己的客户端负载平衡器，维护本地缓存）当你的微服务试图在它们内部进行通信时，只是为了避免服务发现代理（eureka）的负担，而不是每次都检查另一个的地址微服务。
Note: In the flow diagram, please don't confuse the path from API
Gateway --> Service Discovery --> to Microservice as if the Gateway is
forwarding request to Service Discovery that later routes it forward.
Gateway is just checking for the services registry from the Discovery
agents and then routing it to the correct microservice (Not through
the Service Discovery agent)
DNS 负责将请求路由到给定域名的网络内最近的 IP 地址。
Api网关负责认证，找到正确的apis（有或没有负载均衡器）来调用和电路制动，响应整合。
负载均衡器负责根据负载或循环方式将传入请求分发到部署有相同服务的不同机器。
所以一种方法是
DNS 到 LB 的网关
注意：根据流量和用例，LB 可以放在网关之前
我一直从事移动技术方面的工作，现在我正在涉足后端系统，更具体地说是系统设计。对于 api 网关和负载均衡器的角色，我不断遇到相互矛盾的说法。谷歌搜索只返回了相同的六个结果，这些结果主要集中在一些著名服务提供的负载均衡器或 api 网关服务的实现上。我会在这里列出我面临的所有困惑，希望有人能澄清所有这些问题。
有时，我发现 API 网关是与客户端设备的单点通信。另一方面，有些地方提到'request goes to load balancer, which spreads it across servers equally'。那么什么是正确的呢？ API 网关接收请求或负载均衡器？
其他地方，我google了题目，说两者完全不同。我知道 API 网关做了很多事情，比如 SSL 终止、日志记录、节流、验证等，但它也做负载平衡。那么API网关本身就是一个负载均衡器，还配备了其他职责？
关于这个话题，我想了解负载均衡器是在同一集群的服务器之间分配负载还是跨不同的数据中心或集群？ API 网关呢？
api 网关有什么特别之处，以至于它是微服务架构的默认选择？ API 网关托管在哪里？ DNS 将域名解析为负载平衡器或 api 网关？
很明显，我完全糊涂了。如果问题正确，负载均衡器在哪些系统中比 API 网关更受益。
API 网关和负载均衡器是两个不同的东西。
Load Balancer -> 它是一种在协议或套接字级别（例如 tcp、http 或端口 3306 等）工作的软件。它的工作是通过将传入流量分配到具有各种逻辑的目的地来平衡传入流量（例如循环法）。 我不提供授权检查、请求身份验证等功能
鉴于
API 网关 -> 它是各种托管公司提供的托管服务，用于管理 API 操作以无缝扩展 API 基础设施。 它负责访问控制、响应缓存、响应类型、授权、身份验证、请求限制、数据处理、根据自定义规则识别正确的目的地以及无缝扩展后端。 Generally Managed API 网关默认带有可扩展的基础设施，因此将它们放在负载均衡器后面可能没有意义。
关于解析域，很可能总是 DNS 解析到负载均衡器，而负载均衡器又从 API 网关服务获取响应。
DNS -> Load Balancer -> API gateway -> Backend service
希望我能解释清楚你的困惑。
API 网关主要进行 API 管理并提供各种其他关键功能，例如 IAM（身份和访问管理）、速率限制、断路器。因此，它主要消除了为每个微服务实现安全、缓存、节流和监控等功能的 API 特定代码的需要。微服务通常在 API 网关的帮助下公开 REST API 用于前端、其他微服务和第三方应用程序。
但是，一般情况下，API管理不包含负载均衡功能，所以需要配合负载均衡器来实现。
在基于 Azure 的系统架构中，有 Azure Application Gateway，它是一个运行在第 7 层的负载均衡器，在使用基于附加信息的路由决策来路由流量方面提供了比传统负载均衡器（第 4 层）更多的功能HTTP 请求的属性或流量的内容。这也可以称为应用程序负载平衡器。它应与 Azure API 管理（API 网关）结合使用。 Azure 有一个在 DNS 级别运行的流量管理器，它使用 DNS 根据流量路由方法和端点的健康状况将客户端请求定向到最合适的服务端点。流量管理器还使用在 DNS 级别配置的规则，并支持将负载分布到多个区域和数据中心。在每个区域或数据中心内，应有应用网关与负载均衡器耦合，应用网关应帮助确定从中获取响应的应用服务器，负载均衡器应帮助负载均衡。
基于 Azure 的系统概述：
以下是一些相关的参考资料：
Azure 应用程序网关 - https://docs.microsoft.com/en-us/azure/application-gateway/application-gateway-introduction
Azure 负载均衡器- https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-overview
Azure 流量管理器 - https://docs.microsoft.com/en-us/azure/traffic-manager/traffic-manager-overview
场景架构-https://docs.microsoft.com/en-us/azure/traffic-manager/traffic-manager-load-balancing-azure
负载均衡器： 它的主要目的是在多个后端系统之间通过负载均衡分配流量。
- 我们可以为不同的后端系统配置不同的路由。
- 我们为负载平衡端点获取静态 IP 地址（通常不适用于 API 网关）
- 可以配置健康检查（通常不适用于 API 网关）
如果是云提供商，通常“还要为闲置付费”
API 网关 : 这也将流量路由到基于 URL
的后端系统BUT，其主要目的是针对“API管理”。 以下是“负载均衡器”通常不提供的关键功能，
- 可以实现速率限制，突发限制
- 可以进行请求验证和request/response映射
- 通常云 API 网关允许使用 swagger 规范 export/import 跨 API 平台
- 允许缓存响应
对于云提供商，通常是“按使用付费”
这里有两种情况需要考虑以澄清混淆。我已经使用微服务示例对此进行了澄清，因为这仅在那里才有意义。
场景 1：您有一个 API 网关集群
用户 ---> 负载均衡器（由 AWS 等云提供商或您自己提供）---> API 网关集群 ---> 服务发现代理（如 eureka) ---> 微服务 A ---> 客户端负载均衡器 ---> 微服务 B
场景 2：您有一个 单个 API 网关
用户 ---> API 网关 ---> 服务发现代理（如 Eureka）---> 微服务 A ---> 客户端负载平衡器 -> 微服务 B
我希望你明白为什么我们在场景 1 中的 API 网关之前需要负载均衡器，因为我们有多个 API 网关实例也可以处理大流量并避免负担在单个 api 网关上，因为网关本身可以根据需要管理多个 tasks，所以为了在它们之间分配负载，我们有负载平衡器。
在微服务环境中，您可能需要在多个地方使用负载均衡概念。喜欢接受外部网络，您将维护由 AWS 等云提供商提供的负载均衡器，eureka（服务发现）如果注册了相同服务的多个实例，也可以充当负载均衡器，最后我们还有客户端负载平衡（每个微服务都有自己的客户端负载平衡器，维护本地缓存）当你的微服务试图在它们内部进行通信时，只是为了避免服务发现代理（eureka）的负担，而不是每次都检查另一个的地址微服务。
Note: In the flow diagram, please don't confuse the path from API Gateway --> Service Discovery --> to Microservice as if the Gateway is forwarding request to Service Discovery that later routes it forward. Gateway is just checking for the services registry from the Discovery agents and then routing it to the correct microservice (Not through the Service Discovery agent)
DNS 负责将请求路由到给定域名的网络内最近的 IP 地址。
Api网关负责认证，找到正确的apis（有或没有负载均衡器）来调用和电路制动，响应整合。
负载均衡器负责根据负载或循环方式将传入请求分发到部署有相同服务的不同机器。
所以一种方法是 DNS 到 LB 的网关
注意：根据流量和用例，LB 可以放在网关之前