gRPC负载平衡

 

为什么选择gRPC?

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

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

此外,gRPC与生态系统组件无缝集成,例如服务发现,名称解析器,负载平衡器,跟踪和监视等。

负载均衡选项

代理还是客户端?

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

在代理负载平衡与客户端负载平衡之间进行选择是主要的体系结构选择。在代理负载平衡中,客户端将RPC发行给负载平衡器(LB)代理。LB将RPC调用分发到实现了实际服务调用逻辑的可用后端服务器之一。LB跟踪每个后端的负载,并实现用于公平分配负载的算法。客户端本身不了解后端服务器。客户可能不受信任。此体系结构通常用于面向用户的服务,开放式Internet的客户端可以将其连接到数据中心中的服务器,如下图所示。在这种情况下,客户端向LB(#1)发出请求。LB将请求传递给后端之一(#2),后端将报告加载到LB(#3)。

图片替代文字

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

图片替代文字

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

  代理 客户端
优点
  • 简单的客户
  • 客户端没有后端意识
  • 与不受信任的客户一起工作
  • 高性能,因为消除了多余的跃点
缺点
  • 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(运输)与L7(应用)

用例 建议
RPC负载在连接之间变化很大 使用应用程序级别LB
存储或计算亲和力很重要 使用应用程序级别LB并使用cookie或类似内容路由请求以更正后端
最大限度地减少代理中的资源利用率比功能更重要 使用L3 / L4 LB
延迟至高无上 使用L3 / L4 LB

客户端LB选项

胖客户

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

后备负载均衡

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

通过后备负载均衡,可以在特殊的LB服务器中实现负载均衡智能。客户端查询后备LB,并且LB响应以使用最佳服务器。在后备LB中巩固了保持服务器状态和LB算法实现的繁重工作。请注意,客户端可能会选择在LB中实现的复杂算法之上实现简单算法。gRPC使用此模型定义了客户端和LB之间的通信协议。请参阅gRPC文档中的负载平衡 有关详细信息。

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

图片替代文字

建议和最佳做法

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

设定 建议
  • 客户端和服务器之间的流量非常大
  • 客户可以信赖
  • 丰富的客户端负载平衡
  • 带ZooKeeper / Etcd / Consul / Eureka的客户端LB。ZooKeeper示例
  • 传统设置-许多客户端连接到代理后面的服务
  • 在服务器和客户端之间需要信任边界
  • 代理负载平衡
  • 具有GCLB的L3 / L4 LB(如果使用GCP)
  • 具有haproxy的L3 / L4 LB-配置文件
  • Nginx即将推出
  • 如果需要会话粘性-使用Envoy作为代理的L7 LB
  • 微服务-数据中心中的N个客户端,M个服务器
  • 极高的性能要求(低延迟,高流量)
  • 客户可能不受信任
  • 后备负载均衡
  • 使用gRPC-LB协议的客户端LB推出您自己的实现(Q2'17),将gRPC-LB托管在工作中。
  • 现有的服务网格,例如使用Linkerd或Istio进行的设置
原文地址:https://www.cnblogs.com/a00ium/p/14158579.html