gRPC 负载均衡

本文描述了部署 gRPC 时遇到的各种负载均衡场景。如果您将 gRPC 与多个后端一起使用，本文档适合您。

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

为什么选择 gRPC？

gRPC 是一种基于 HTTP/2 实现的现代 RPC 协议。HTTP/2 是一种在 TCP（层 4 - 传输层）协议之上运行的第 7 层（应用层）协议，而 TCP 又在 IP（层 3 - 网络层）协议之上运行。gRPC 相较于传统的 HTTP/REST/JSON 机制具有许多优势，例如：

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

此外，gRPC 与服务发现、名称解析器、负载均衡器、追踪和监控等生态系统组件无缝集成。

负载均衡选项

代理侧还是客户端侧？

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

在代理负载均衡和客户端负载均衡之间做出选择是首要的架构决策。在代理负载均衡中，客户端向负载均衡器 (LB) 代理发出 RPC。LB 将 RPC 调用分发给其中一个可用的后端服务器，这些服务器实现了处理调用的实际逻辑。LB 会跟踪每个后端上的负载，并实现算法以公平地分配负载。客户端本身不了解后端服务器。客户端可能不受信任。这种架构通常用于面向用户的服务，其中来自开放互联网的客户端可以连接到数据中心的服务器，如下图所示。在这种场景中，客户端向 LB 发出请求 (#1)。LB 将请求转发给其中一个后端 (#2)，后端则向 LB 报告负载 (#3)。

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

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

代理负载均衡器选项

代理负载均衡可以是 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 (应用层)

客户端负载均衡选项

厚客户端

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

旁路负载均衡

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

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

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

建议与最佳实践

根据具体的部署和限制，我们建议如下：

• ←上一篇
下一篇→