RSS

gRPC 负载均衡

本文介绍了部署 gRPC 时遇到的各种负载均衡场景。如果您使用 gRPC 与多个后端,本文档适合您。

大规模 gRPC 部署通常有多个相同的后端实例和多个客户端。每个服务器都有一定的容量。负载均衡用于将客户端的负载最佳地分配到可用的服务器上。

为什么选择 gRPC?

gRPC 是在 HTTP/2 之上实现的现代 RPC 协议。HTTP/2 是一个第 7 层(应用层)协议,它运行在 TCP(第 4 层 - 传输层)协议之上,而 TCP 又运行在 IP(第 3 层 - 网络层)协议之上。与传统的 HTTP/REST/JSON 机制相比,gRPC 有许多优势,例如:

  1. 二进制协议 (HTTP/2)
  2. 在一个连接上复用多个请求 (HTTP/2)
  3. 头部压缩 (HTTP/2)
  4. 强类型的服务和消息定义 (Protobuf)
  5. 多种语言中的惯用客户端/服务器库实现

此外,gRPC 还与其他生态系统组件(如服务发现、名称解析器、负载均衡器、跟踪和监控等)无缝集成。

负载均衡选项

代理还是客户端?

注意:在某些文献中,代理负载均衡也称为服务器端负载均衡。

决定使用代理还是客户端负载均衡是一个主要架构选择。在代理负载均衡中,客户端向负载均衡器 (LB) 代理发出 RPC。LB 将 RPC 调用分发到实现服务调用的实际逻辑的可用后端服务器之一。LB 跟踪每个后端上的负载,并实现算法来公平地分配负载。客户端本身不知道后端服务器。客户端可能是不可信的。此架构通常用于面向用户的服务,其中来自开放互联网的客户端可以连接到数据中心的服务器,如下图所示。在这种情况下,客户端向 LB 发出请求 (#1)。LB 将请求传递给其中一个后端 (#2),后端向 LB 报告负载 (#3)。

image alt text

在客户端负载均衡中,客户端知道多个后端服务器,并为每个 RPC 选择一个使用。客户端从后端服务器获取负载报告,并且客户端实现负载均衡算法。在较简单的配置中,不考虑服务器负载,客户端可以在可用服务器之间进行轮询。如下图所示。如您所见,客户端向特定的后端发出请求 (#1)。后端使用负载信息进行响应 (#2),通常在客户端 RPC 执行的同一连接上。然后,客户端更新其内部状态。

image alt text

下表概述了每种模型的优缺点。

代理客户端
优点
  • 简单的客户端
  • 客户端无需了解后端
  • 适用于不可信的客户端
  • 由于消除了额外的跳跃,因此性能高
缺点
  • LB 在数据路径中
  • 延迟较高
  • LB 吞吐量可能会限制可伸缩性
  • 复杂的客户端
  • 客户端跟踪服务器负载和运行状况
  • 客户端实现负载均衡算法
  • 每个语言的实现和维护负担
  • 客户端需要是受信任的,或者信任边界需要由旁路 LB 处理。

代理负载均衡器选项

代理负载均衡可以是 L3/L4(传输层)或 L7(应用层)。在传输层负载均衡中,服务器终止 TCP 连接,并打开另一个到所选后端的连接。应用程序数据(HTTP/2 和 gRPC 帧)只是在客户端连接和后端连接之间复制。L3/L4 LB 的设计处理很少,与 L7 LB 相比,增加了更少的延迟,并且因为它消耗更少的资源而更便宜。

在 L7 (应用层) 负载均衡中,LB 终止并解析 HTTP/2 协议。LB 可以检查每个请求,并根据请求内容分配后端。例如,作为 HTTP 标头发送的会话 cookie 可以用来关联特定的后端,因此该会话的所有请求都由相同的后端服务。一旦 LB 选择了一个合适的后端,它会创建一个到该后端的新 HTTP/2 连接。然后,它将从客户端接收到的 HTTP/2 流转发到选择的后端。使用 HTTP/2,LB 可以将来自一个客户端的流分配到多个后端。

L3/L4(传输层) vs L7(应用层)

用例建议
RPC 连接间的负载变化很大使用应用层 LB
存储或计算亲和性很重要使用应用层 LB,并使用 cookie 或类似机制将请求路由到正确的后端
在代理中最小化资源利用率比功能更重要使用 L3/L4 LB
延迟至关重要使用 L3/L4 LB

客户端负载均衡选项

胖客户端

“胖”客户端方法意味着负载均衡的智能在客户端实现。客户端负责跟踪可用的服务器、它们的工作负载以及用于选择服务器的算法。客户端通常集成与服务发现、名称解析、配额管理等其他基础设施通信的库。

旁路负载均衡

注意:旁路负载均衡器也称为外部负载均衡器或单臂负载均衡器

使用旁路负载均衡时,负载均衡的智能在特殊的 LB 服务器中实现。客户端查询旁路 LB,LB 会响应要使用的最佳服务器。保持服务器状态和实现 LB 算法的繁重工作都整合在旁路 LB 中。请注意,客户端可能会选择在 LB 中实现的复杂算法之上实现简单的算法。gRPC 定义了一个使用此模型在客户端和 LB 之间进行通信的协议。有关详细信息,请参阅 gRPC 中的负载均衡 文档

下图说明了这种方法。客户端从旁路 LB 获取至少一个地址 (#1)。然后,客户端使用此地址进行 RPC (#2),服务器向 LB 发送负载报告 (#3)。旁路 LB 与其他基础设施(如名称解析、服务发现等)通信 (#4)。

image alt text

建议和最佳实践

根据特定的部署和约束,我们建议如下。

设置建议
  • 客户端和服务器之间有非常高的流量
  • 客户端是可信的
  • “胖”客户端负载均衡
  • 客户端 LB 与 ZooKeeper/Etcd/Consul/Eureka。ZooKeeper 示例
  • 传统设置 - 许多客户端连接到代理后面的服务
  • 需要在服务器和客户端之间建立信任边界
  • 代理负载均衡
  • 使用 GCLB 的 L3/L4 LB(如果使用 GCP)
  • 使用 haproxy 的 L3/L4 LB - 配置文件
  • Nginx 即将推出
  • 如果需要会话粘性 - 使用 Envoy 作为代理的 L7 LB
  • 微服务 - 数据中心中有 N 个客户端和 M 个服务器
  • 非常高的性能要求(低延迟、高流量)
  • 客户端是不可信的
  • 旁路负载均衡
  • 使用 gRPC-LB 协议 的客户端 LB。自己实现(2017 年第 2 季度),托管 gRPC-LB 正在开发中。
  • 使用 Linkerd 或 Istio 等现有服务网格设置
  • 服务网格
  • 使用 IstioEnvoy 的内置 LB。