为什么对gRPC做负载均衡会很棘手？

null

在过去的几年中，随着微服务的增长，gRPC在这些较小的服务之间的相互通信中获得了很大的普及,在后台，gRPC使用http/2在同一连接和双工流中复用许多请求。

使用具有结构化数据的快速，轻便的二进制协议作为服务之间的通信介质确实很有吸引力，但是使用gRPC时需要考虑一些因素，最重要的是如何处理负载均衡。

gRPC使用粘性连接

gRPC连接是粘性的。这意味着当从客户端到服务器建立连接时，相同的连接将被尽可能长时间地用于许多请求（多路复用）。这样做是为了避免所有最初的时间和资源花费在TCP握手上。因此，当客户端获取与服务器实例的连接时，它将保持连接。

现在，当同一客户端开始发送大量请求时，它们都将转到同一服务器实例。而这正是问题所在，将没有机会将负载分配给其他实例。他们都去同一个实例。

这就是为什么粘性连接会使负载平衡变得非常困难。

以下是一些负载均衡gRPC相互通信的方法，以及每种方法的一些细节。

1.服务器端

当在服务器端完成负载均衡时，会使客户端非常精简，并且完全不知道如何在服务器上处理负载：

网络负载均衡器

null

网络负载均衡器在OSI (Open Systems Interconnection) 模型的第4层运行。因此，它非常快，可以处理更多的连接。当出现新的TCP通信连接时，负载均衡器将选择一个实例，并且在连接有效期内将连接路由到该单个实例。

现在请记住，gRPC连接是粘性的和持久的，因此它会在负载均衡器后面的客户端和同一服务器实例之间保持相同的连接，只要它可以。

现在这是问题所在：

粘性连接和自动缩放

如果单个服务器实例上的负载（内存或cpu）高于自动伸缩策略，则将导致在该目标组中启动一个新实例。

但是，目标组中的新实例将无济于事。为什么？同样，因为gRPC连接是持久的且具有粘性。正在发送大量请求的客户端，将继续将它们发送到与其连接的同一服务器实例。

因此，新的服务器实例被启动，但是没有请求过载将流向新的实例。利用率高的同一台单服务器实例仍在接收来自客户端的请求负载（因为客户端一直在重用相同的连接）。

自动伸缩策略可能会不断触发并向目标组添加新实例（因为单个实例的cpu /内存过载）。但是这些新实例接收的流量几乎为零。自动缩放策略可能会继续触发并可能最大化目标组中允许的实例，而实际上并未从发送到新实例的请求中受益。

如何使用gRPC粘性连接分配负载？

为了基本上有机会分配负载，我们必须使用以下方法之一放弃粘性和持久连接：

1.客户端定期重新连接

如果您可以控制连接的gRPC客户端，则可以强制客户端定期断开连接并重新连接。此行为将迫使客户端向负载均衡器发送新请求，并且作为对此请求的响应，这次将返回更健康的实例。

2.服务器定期强制断开客户端连接

如果您无法控制连接的gRPC客户端，则可以在服务器端实现类似的逻辑。使服务器在一段时间后强行关闭连接，当它们重新连接时，它会自动使新连接进入更健康的实例。

这些方法中的任何一种都丢失了gRPC的基本优势：可重用的连接。

DNS服务发现

同样，我们可以将服务器实例放置在DNS服务发现之后，而不是在Elastic Load Balancer后面。服务发现本质上是一种DNS服务，当请求进入时，它将以随机顺序返回其后面所有实例（或正常实例的子集）的IP地址列表。因此，当客户端选择要连接到的服务器并进行DNS查找时，服务发现将返回排序后的实例的IP地址。

网络负载均衡器的所有问题几乎都适用于DNS服务发现负载均衡。当客户端获取到单个实例的连接时，它将坚持并继续重用它。