为什么加载平衡GRPC很棘手？

随着过去几年微服务的增长，GRPC在这些较小的服务之间进行了很多人气。在幕后，GRPC使用HTTP / 2来多用同一连接内的许多请求和双工流。

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

GRPC连接是粘性的。意思是，当从客户端到服务器进行连接时，可以为许多请求（多路复用）重复使用相同的连接，只要尽可能长。这是为了避免为TCP握手花费的所有初始时间和资源。因此，当客户端抓取到服务器实例时，它将保持它。

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

以下是负载平衡GRPC间通信和各种方法的一些方法的方法。

当在服务器端完成负载平衡时，它会使客户端非常瘦，完全不知道它在服务器上处理方式：

网络负载平衡器在OSI（开放系统互连）模型的第4层处运行。因此它非常快，可以处理更多的连接。当新的TCP流量连接进入时，负载均衡器选择实例，并将连接路由到连接的寿命的该单一实例。

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

如果单个服务器实例上的加载（内存或CPU）高于自动缩放策略，则会导致新实例在该目标组中旋转。

但目标组中的一个新实例不会有所帮助。为什么？同样，因为GRPC连接是持久性和粘性的。发送大量请求的客户端将继续向他们发送相同的服务器实例它具有连接。

因此，新的服务器实例已旋转，但没有一个请求过载将进入新实例。具有沉重用法的单个服务器实例仍在接收来自客户端的请求（因为客户端保留同一连接）。

有可能使自动缩放策略保持触发并向目标组添加新实例（因为有一个具有过载的CPU /内存的单个实例）。但这些新实例接近零流量。自动缩放策略可以继续触发并可能最大化目标组中的允许实例，而无需实际受益于发送到新实例的请求。

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

如果您对连接GRPC客户端进行了控制，则可以将客户端定期断开连接并重新连接。这一动作将强制客户将新请求向负载均衡器发送并作为对此请求的响应，这次将此时间更健康实例回。这种技术强制负载是平衡的。

如果您没有控制连接GRPC客户端，则可以在服务器端实现类似的逻辑。使服务器在某个时候强制关闭连接，当他们重新连接时，它会自动导致新的连接转到更健康的实例。

AWS应用程序负载均衡器是第7层负载均衡器和支持HTTP / 2，直到10月20日至10月20日，HTTP / 2的支持仅从客户端到负载均衡器。然后，将连接从负载均衡器从负载均衡器中降级到HTTP / 1.1到BALB背后的支持目标实例。

因此，此前您无法使用GRPC使用ALB，因为它一直需要HTTP / 2。

但是，在2010年10月.2020。AWS宣布，ALB现在一直支持HTTP / 2，使其非常适合GRPC通信。

虽然ALB的此功能相对较新，但粘性GRPC连接和NLB的参数也适用于ALB。如果yu从开始发送大量请求的客户端的单个粘性和持久的连接，则重新装载一个服务器实例，该服务器实例可容纳连接，并且请求不是应加载均衡。

同样，我们可以将我们的服务器实例放在DNS服务发现后，而不是弹性负载平衡器。服务发现基本上是DNS服务，当请求进入时，它将以随机顺序返回其后面的所有实例的IP地址列表（或健康的子集）。因此，当客户端选择要连接的服务器并执行DNS查找时，服务发现返回排序的备份实例的IP地址。

几乎所有与NLB的关注都适用于DNS服务发现负载平衡。当客户端抓住与单个实例的连接时，它将坚持并继续重新使用。无论它如何找到服务器实例，都是IT ALB，NLB或服务发现。

如果您完全控制客户端，可以在客户端实现负载平衡逻辑。使客户端了解所有可用的服务器及其健康以及选择连接到的所有服务器和选择哪一个。这将导致客户在逻辑中更重。因此，它们不仅应该包含逻辑要做他们应该做的事情，而且还需要实现负载平衡，健康检查等的逻辑。

这是一个可行的选项，在一个条件下：如果您完全控制所有客户端。您不能让错误的客户端连接到您的服务并导致各种负载平衡问题。它只需要一个有缺陷的客户来引起足够的麻烦。

根据官方GRPC负载均衡的推荐，此方法使用外部负载均衡器或单臂负载均衡器，用于在服务器实例之间分发流量。

客户端达到外部服务，它将返回可用服务器，服务发现和所有其他所需信息的列表。

理想情况下，客户端将有一些逻辑，也可以帮助决定决定。这种方法容易出于上面提到的粘性连接的问题，因此需要仔细实施。

官方实现使用每个呼叫负载平衡，而不是每个连接。所以每个呼叫都是单独平衡的负载。这是理想的和理想的情况，它将避免具有沉重的粘性连接。

看看检查所有框，还有一个大缺点：它需要一个完全专用的服务。

因此，要从外观负载均衡中受益，您需要实现并部署一个全新的专用服务，只需加载您的其他服务之间的GRPC连接。每项新服务都有自己的维护，操作，监控，警报等。

服务器端负载平衡，具有非常重要的问题，我们无法受​​益于GRPC的主要优点，这是粘性可重复使用的连接。

客户端负载平衡，需要完全控制客户端，如果有一个错误的客户端，它可能会破坏所有的计划。

看起来除了负载平衡，是负载均衡Grpc连接的最逻辑和性能的解决方案，但它需要自己的完整和专用服务，这意味着架构中的新服务来实现和操作。也是一个新的失败点。

处理GRPC架构中负载增加的关注和挑战是一个重要的。它需要适当关注妥善处理，解决方案取决于我们所拥有的情况。

最后，作为软件工程中的所有其他东西，GRPC都带来了贸易问题。意识到贸易问题是至关重要的，并相应地选择。

如果您发现本文有趣，您可以在Twitter上关注我，因为我在那里分享了我的学习。