gRPC 负载均衡

本文介绍了部署 gRPC 时遇到的各种负载均衡场景。如果您使用多个后端部署 gRPC，本文将对您有所帮助。

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

为什么选择 gRPC？

gRPC 是一种基于 HTTP/2 实现的现代化 RPC 协议。HTTP/2 是一个运行在 TCP (第四层 - 传输层) 协议之上的第七层 (应用层) 协议，而 TCP 又运行在 IP (第三层 - 网络层) 协议之上。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)。

建议和最佳实践

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

• ←上一页
下一页→