grpc 负载均衡

说明

本文档介绍了 gRPC中，负载均衡的设计思想

底层实现

每次调用的负载均衡

值得注意的是gRPC的负载均衡是建立在单个调用的基础之上，而不是单个连接。换句话说，即使所有的请求都来自一个客户端，我们的期望是调用是平均分配在所有的服务器服务器上的。

实现均衡的方式

在介绍任何gRPC实现细节之前，我们探索一些实现负载平衡的常用方法。

proxy model 【代理模式】

代理模式能够可靠的将客户端的请求分配到各服务器。但是代理通常需要更多的资源，因为它们复制了rpc请求和响应，这种模型下，还增加了 RPC 请求的延迟。

当考虑请求大量服务（例如存储）场景时，代理模型效率不足。

Balancing-aware Client 【客户端进程内负载均衡】

这种重客户端的模式下，客户端自己独立负责负载均衡逻辑控制，如使用某种类型的负载均衡策略（如轮训，随机）等，从一个服务器列表中选择服务器。在此模型中，服务器列表是静态配置在客户端中，或是由名称解析系统提供，或者是额外的负载均衡器，无论何种方式，客户端自己负载选择服务器。

这种方式的主要缺点是：研发维护成本，该方案将服务调用集成在客户端里面，如果有多种不同的语言栈，就要配合研发多种不同的客户单，有一定的研发维护成本，更新服务端的时候，需要同步更新客户端。

External Load Balancing Service 【外部负载均衡服务】

客户端负载均衡代码保持简单便捷，仅实现通用的服务器选择算法，更复杂的计算由负载均衡服务提供，客户端依靠负载均衡服务提供配置以及服务器列表等。均衡服务器负责根据服务器的可用状态，健康状态，作出决策，来更新服务列表等，并通知客户端，均衡服务同时和后端服务通信，收集负载和健康信息。

gRPC 负载均衡的要求

简答的api 和 client

gRPC客户端负载均衡的代码必须简单，轻量。代码仅包含选择服务器的简单算法。对于复杂算法，客户端应该依赖负载均衡器提供的均衡配置和客户端应发请求的服务列表。

安全性

均衡器可能与后端服务分开，并且均衡器的危害应仅能导致平衡器功能的损害。换句话说，受到破坏的均衡器应不能够导致客户端信任（可能恶意的）后端服务。

架构

概览

gRPC中负载平衡的主要机制是外部负载均衡服务，其中外部负载平衡器为简单的客户端提供服务器的最新列表。

gRPC客户端确实支持用于内置负载平衡策略的API，但是只有其中一小部分（其中一个是grpclb，实现了外部负载均衡），并且不鼓励用户通过添加更多内容来gRPC策略。相反，新的负载均衡策略应该在外部负载均衡器中实现。

grpc 负载均衡流程

在名称解析和与服务器的连接之间，负载平衡策略适用于gRPC客户端工作流。运作方式如下：

grpc workflow

开始 gRPC client 会发起一个服务器名称解析请求。服务器名称会被解析为若干个 IP地址，每个ip会表明自己是一个服务地址或是负载均衡器地址，同时表明，服务配置中希望客户端使用哪种负载均衡策略（round_bin, grpclb）
客户端实例化负载均衡策略。

注意：任何被解析服务返回的地址如果是一个负载均衡地址，client 将使用 grpclb 策略，无论服务配置中要求使用哪种负载均衡策略。其它的将使用服务配置中要求的策略。如果没有策略，客户端选择第一个可用的服务。

负载均衡策略为每个服务创建一个子通道【subchannel】。

除了 grpclb，策略解析器会为每个地址创建一个子通道。
grpclb 的工作流如下：
- a. grpclb会在 resolver返回的负载均衡器地址上打开一个流连接。客户端会从这个流中，根据名称获取到需要的服务器地址。
注意: 在grpclb 策略下，非负载均衡器地址会以回调的方式使用，以防LB策略启动的时候，没有均衡器可连接。
- b. 如果负载均衡器配置需要知道服务的负载情况，则服务器会上报该负载
- c. 负载均衡器会返回一个服务器列表给gRPC客户端的 grpcLB策略。grpclb会为每个服务创建一个子通道

对于每一个 RPC 发送，负载均衡策略决定将它发送到哪个子通道去

grpclb策略的场景下，客户端到服务器的请求是以他们被负载均衡器返回的顺序发送的。如果服务器列表为空，请求将阻塞到有一个非空的服务返回为止。

名词解释

policy 策略
load balancer 负载均衡器
Name Resolver 名称解析器，如dns
subchannel 子通道

参考：grpc 负载均衡
参考：gRPC Name Resolution