原文地址：https://github.com/grpc/grpc/blob/master/doc/load-balancing.md

gRPC负载均衡

范围

背景

每次调用的负载均衡

负载均衡的方式

代理模式

代理提供一个可靠的可以上报负载情况到负载均衡系统的客户端，因为代理会暂时的保留RPC请求和响应的副本，所以通常它们需要更多的资源。这个模式也增加了PRC的延迟。

在考虑到请求压力较重的服务，例如存储服务，代理模式被认为是效率低下的。

客户端感知负载

这个更厚的客户端将更多的负载均衡逻辑放在客户端。例如，客户端会包含许多负载均衡策略(轮询，随机等)用于在一个列表中选择服务。这个模式下，一个由名称解析系统或外部的负载均衡器等提供的服务器的列表会被静态的配置在客户端，这种情况下，客户端负责从列表中选择最佳的服务器

这个方法的其中一个缺点是需要编写和维护包含多种语言或版本的负载均衡策略的客户端。那些策略可能会非常的复杂。一些算法需要客户端与服务端的交互，所以客户端可能需要变得更厚来提供额外的RPC用来健康检查或从用户发送的RPC请求中获取额外的负载信息。

它也会使客户端的代码变得复杂：新的设计要隐藏多层负载均衡的复杂性使之就像是一个对于客户端的简单的服务端列表。

外部负载均衡服务

客户端负载均衡代码保持简单且可移植，实现了众所周知的算法(例如:轮询调度)用于选择服务。负载均衡器提供更复杂的负载均衡算法。客户端依赖于负载均衡器提供负载均衡配置以及一个客户端要发送请求到的服务器列表。当服务不可用或健康问题出现时，均衡器会更新需要均衡负载的服务器列表。负载均衡器会做出任何复杂的必须的决定并通知客户端。负载均衡器会和后端的服务器交互来收集负载和健康信息。

需求

简单的API和客户端

安全性

架构

综述

gPRC客户端提供一个API来支持内置的负载均衡策略，然而，只有很少数(其中一个是grpclb策略实现了一个外部负载均衡器)，并且不鼓励用户尝试添加更多的来扩展gRPC。相反的，新的负载均衡策略应该实现在外部的负载均衡器上。

工作流

1. 启动时，gPRC客户端通过服务名发起一个名称解析请求。名称会被解析为一个或更多的IP地址，每个地址指明它是一个服务器地址或一个负载均衡器地址，并且包含一个服务器配置指明那一个客户端的负载均衡策略应该被使用(例如: 轮询调度或grpclb)

2. 客户端实现一个负载均衡策略。

• 注意：如果任何一个被解析器返回的地址是均衡器地址，那么这个客户端会使用grpclb策略，而不管请求的服务配置是那种负载均衡策略。否则，客户端会使用一个请求的服务配置负载均衡策略。如果没有负载均衡策略，那么客户端会使用默认的取第一个可用服务器地址的策略。

3. 负载均衡策略对每一个服务器地址创建一个子通道。

• 除了grpclb以外的所有策略，这意味每个被解析器返回的地址的子通道。需要注意的是这些策略会忽略任何被解析器返回的均衡器地址。
• grpclb策略，工作流如下：
  • 这个策略打开一个从解析器返回的均衡器地址之一的流。它使用客户端请求的服务器名称请求均衡器来获取服务器地址(例如: 和传递给名称解析器的相同的名称)
    • 注意：在grpclb策略中，解析器返回的非解析器地址用于后备来防止在负载均衡策略启动后没有均衡器能够用来交互。
  • 负载均衡器给客户端指向的gRPC服务器应该在负载均衡器的配置需要报告负载信息信息时报告负载信息给负载均衡器
  • 负载均衡器返回一个服务器列表给gRPC客户端的grpclb策略。grpclb策略对每个列表中的服务器创建一个子通道。

4. 对于每个PRC发送请求，负载均衡策略决定应该发送到哪个子通道(例如: 哪个服务器)。

• grpclb策略下，客户端按负载均衡器返回的顺序发送请求到服务器。如果服务器列表为空，调用将会阻塞直到收到一个非空的列表。

原文地址：https://www.cnblogs.com/qq332398135/p/8525425.html