原文:Load Balancing in gRPC June 15, 2017 makdharma, Google
翻译整理: 陈进涛 译文链接:【译】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跟踪每个后端上的负载，并实现公平分配负载的算法。客户机本身并不知道后端服务器。客户可能是不可信的。此体系结构通常用于面向用户的服务，其中来自开放internet的客户端可以连接到数据中心中的服务器，如下图所示。在这个场景中，客户机向LB发出请求(#1)。LB将请求传递给其中一个后端(#2)，后端将负载报告给LB(#3)。

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

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

	代理模式	客户端模式
优点	客户端对后端无感知。可以与不受信任的客户端一起使用	高性能，因为消除了多余的跃点
缺点	1. LB在数据路径中 2. 更高的延迟 3. LB吞吐量可能限制其伸缩性	1.复杂的客户端 2. 客户端跟踪服务器负载和运行状况 3.客户端实现负载均衡算法 4.每种语言的实现和维护负担 5.客户端需要被信任，或者信任边界需要由后备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

客户端负载均衡选项

胖客户端

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

后备（lookaside）负载均衡

注意：后备负载均衡器也称为外部负载均衡器或单臂负载均衡器

通过后备负载均衡，可以在专用的LB服务器中实现负载均衡智能。客户端请求后备LB，LB响应以可使用的最佳服务器列表。在后备LB中统一了保持服务器状态和LB算法实现的繁重工作。 请注意，客户端可能会选择在LB中实现的复杂算法之上实现简单算法。gRPC使用此模型定义了一个客户端和LB之间的通信协议。查看文章 Load Balancing in gRPC (该文档译文:【译】gRPC负载均衡)以获得详细信息.

下图说明了这种方法。 客户端从后备LB（＃1）获得至少一个地址。 然后，客户端使用该地址进行RPC（＃2），然后服务器将负载报告发送到LB（＃3）。 后备LB与其他基础结构进行通信，例如名称解析，服务发现等（＃4）。

推荐和最佳实践

根据特定的部署和约束条件，我们建议以下内容。

设置（Setup）	建议
1.客户端和服务器之间的流量非常大 2.客户端可以被信任	胖客户端负载均衡 客户端LB + ZooKeeper/Etcd/Consul/Eureka.ZooKeeper Example.
1.传统设置-许多客户端通过代理连接到服务 2.需要在服务器和客户端之间设置信任边界	代理负载均衡 1.使用GCLB（谷歌云负载均衡）的L3/L4 LB（如果使用谷歌云平台） 2.使用haproxy的L3/L4 LB - Config file 3.Nginx就要支持了（备注：NGINX 1.13.10已经支持） 4.如果需要会话粘性-使用Envoy作为代理的L7 LB
1.微服务-数据中心中有N个客户端，M个服务器 2.极高的性能要求（低延迟，高流量） 3.客户可以是不受信任的	后备（lookaside）负载均衡 客户端LB使用gRPC-LB protocol.推出你自己的实现，hosted gRPC-LB正在工作中
现有的服务网格，例如使用Linkerd或Istio进行的设置	服务网格 使用Istio, or Envoy的内置LB