gRPC详解-----负载均衡策略

1. 背景

1.1 基于调用的LB

需要注意的是,gRPC的负载均衡是基于每次调用而不是每条连接的.
换句话说,即使所有的请求来自同一个客户端,我们也希望这些请求能够在不同的服务上进行LB.

1.2 LB的实现方法

在介绍任何gRPC的特定实现之前,我们先来浏览一下常见的LB实现方式.
balancing.

1.2.1 代理模式

使用代理能够提供可靠可信任的客户端,还可以向LB系统报告负载情况.
代理通常需要更多的资源和操作,因为代理需要拷贝RPC请求和响应的副本.这种模式也会增加RPC的延迟.

当请求量很大时,代理模式很低效,比如存储服务.

1.2.2 客户端感知的实现

通过较厚的客户端在客户端实现更多的负载均衡逻辑.
比如,客户端可能包含多种LB策略(Round Robin, 随机算法等)来从服务列表中进行选择.
在这种模式中,服务列表可以通过静态配置、命称解析系统、或者外部LB等方式实现.客户端需要从服务列表中选择
合适的服务.

这种实现方式的缺点是需要提供不同语言的客户端实现,以及维护不同的客户端版本.
负载均衡策略可能非常复杂.一些算法需要客户端与服务端交互,客户端需要额外的RPC请求来获取服务端的健康和负载状况.

客户端代码也可能变得复杂:新的设计通过多层次架构来隐藏LB的复杂性,客户端仅仅看到一个服务列表.

1.2.3 外部LB服务

通过这种方式客户端代码能够保持简洁和可移植.
复杂的LB算法由外部LB来实现.
客户端依赖外部LB提供LB的配置和可用的服务列表.
外部LB控制服务的可用和健康性,并根据需要更新可用的服务列表,外部LB做出必要的决策并通知客户端.
LB还可能与后端的服务交行交互来获得负载和健康状态.

2. 需求

2.1 API和客户端简单

gRPC客户端的负载均衡代码必须简洁和可移植.客户端应该只包含简单服务选择算法(如. Round Robin)
对于复杂的算法,客户端应该依靠专门提供负载均衡配置和服务列表的LB.专门的LB会根据服务的负载、可用性、健康
状态等因素更新相应的服务列表,LB将会进行复杂的决策并通知客户端.LB会与后端的服务进行通信以收集服务的负载和
健康状态.

安全

专门的LB和实际的后端服务可能是隔离的,LB功能的受损应该只影响LB功能.
换句话说,如果LB功能受损,和不使用LB相比,导致客户端信任一个潜在不安全的服务的情况不会更坏.

3. 架构

3.1 概览

gRPC主要的LB机制是使用外置的LB,通过外置的LB向客户端提供一个实时更新的服务列表.

gRPC客户端不支持内置LB策略的API.只支持一部分(其中一个是grpclb策略,通过外部LB实现),
gRPC鼓励用户扩展gRPC.新的LB策略应该通过扩展外部LB来实现.

3.2 工作流

LB策略在gRP客户端的流程的命称解析和与服务建立连接之间.

下图是具体的工作流程:

1. 启动时,gRPC客户端提交一个服务名称解析请求.服务名被解析成一个或多个IP地址.每个地址代表一个服务地址或一个LB的地址.
   同时还返回一个服务配置信息,告诉客户端使用何种LB策略(比如,round_robin或者grpclb)
2. 客户端实例化LB策略.
   • 注意: 如果名称解析器返回的地址包含一个LB地址,那么客户端将使用grpclb策略并忽略服务配置中的LB策略
     否则,客户端将使用服务配置中的LB策略.如果没有配置LB策略,那么客户端将为默认策略使用第一个可用的服务地址
3. LB策略为每个服务地址创建一个subchannel.
   • 对于除了grpclb的所有策略,这意味着为名称解析返回的每个地址各创建一个subchannel.
     注意这些策略会忽略返回的LB地址.
   • 如果采用的是grpclb策略,工作流程如下:
     1. 和LB建立一个stream,并向LB请求可用的服务列表.
        • 注意: grpclb策略中,名称解析服务返回的非LB地址将作为备用,如果所有的LB都无法连接成功.
     2. 实际的gRPC服务会向LB报告负载信息,这些信息根据LB的配置有关.
     3. LB向客户端的grpclb策略返回一个服务列表.grpclb策略为服务列表中的每个服务建立一个subchannel.
4. 对于每个RPC请求,对应的LB策略决定使用哪个subchannel.
   • 对于grpclb策略,客户端将按照LB返回的服务顺序依次发送请求.如果服务列表为空,rpc请求将会阻塞直到有可用的服务返回.