值得注意的是gRPC的负载均衡是反生在每次调用的基础上，而不是每条连接的基础上。换言之，即使所有请求都来自于同一个客户端，我们仍旧想要它们被负载到所有的服务器上。
负载均衡的方式在gPRC的负载均衡之前，先研究一下一些常见的负载均衡方式。
代理模式代理提供一个可靠的可以上报负载情况到负载均衡系统的客户端，因为代理会暂时的保留RPC请求和响应的副本，所以通常它们需要更多的资源。这个模式也增加了PRC的延迟。
在考虑到请求压力较重的服务，例如存储服务，代理模式被认为是效率低下的。
客户端感知负载这个更厚的客户端将更多的负载均衡逻辑放在客户端。例如，客户端会包含许多负载均衡策略(轮询，随机等)用于在一个列表中选择服务。这个模式下，一个由名称解析系统或外部的负载均衡器等提供的服务器的列表会被静态的配置在客户端，这种情况下，客户端负责从列表中选择最佳的服务器
这个方法的其中一个缺点是需要编写和维护包含多种语言或版本的负载均衡策略的客户端。那些策略可能会非常的复杂。一些算法需要客户端与服务端的交互，所以客户端可能需要变得更厚来提供额外的RPC用来健康检查或从用户发送的RPC请求中获取额外的负载信息。
它也会使客户端的代码变得复杂：新的设计要隐藏多层负载均衡的复杂性使之就像是一个对于客户端的简单的服务端列表。
外部负载均衡服务客户端负载均衡代码保持简单且可移植，实现了众所周知的算法(例如:轮询调度)用于选择服务。负载均衡器提供更复杂的负载均衡算法。客户端依赖于负载均衡器提供负载均衡配置以及一个客户端要发送请求到的服务器列表。当服务不可用或健康问题出现时，均衡器会更新需要均衡负载的服务器列表。负载均衡器会做出任何复杂的必须的决定并通知客户端。负载均衡器会和后端的服务器交互来收集负载和健康信息。
需求 简单的API和客户端gRPC客户端负载均衡代码必须简单且可移植的。客户端应该只包含简单的算法(例如:轮询调度)来选择服务器。对于复杂的算法，客户端应该依赖于一个负载均衡器来提供负载均衡配置和客户端应该发送请求到的服务器列表。当服务不可用或健康问题出现时，均衡器会更新需要均衡负载的服务器列表。负载均衡器会做出任何复杂的必须的决定并通知客户端。负载均衡器会和后端的服务器交互来收集负载和健康信息。
安全性负载均衡器会和后台服务分开且一个折衷的负载均衡器会导致负载均衡器的负载均衡功能受到损害。换言之，一个折衷的的负载均衡器不应该导致客户端信任一个(可能是恶意的)后端服务器，而不是在没有负载均衡的情况下。
架构 综述gRPC主要的负载均衡机制是外部负载均衡器，一个外部的负载均衡器提供简单的客户端和一个最新的服务器列表
gPRC客户端提供一个API来支持内置的负载均衡策略，然而，只有很少数(其中一个是grpclb策略实现了一个外部负载均衡器)，并且不鼓励用户尝试添加更多的来扩展gRPC。相反的，新的负载均衡策略应该实现在外部的负载均衡器上。
工作流在名称解析和服务器链接中，负载均衡策略适合gPRC客户端工作流。以下是它如何工作的：
1. 启动时，gPRC客户端通过服务名发起一个名称解析请求。名称会被解析为一个或更多的IP地址，每个地址指明它是一个服务器地址或一个负载均衡器地址，并且包含一个服务器配置指明那一个客户端的负载均衡策略应该被使用(例如: 轮询调度或grpclb)
2. 客户端实现一个负载均衡策略。
注意：如果任何一个被解析器返回的地址是均衡器地址，那么这个客户端会使用grpclb策略，而不管请求的服务配置是那种负载均衡策略。否则，客户端会使用一个请求的服务配置负载均衡策略。如果没有负载均衡策略，那么客户端会使用默认的取第一个可用服务器地址的策略。
3. 负载均衡策略对每一个服务器地址创建一个子通道。
除了grpclb以外的所有策略，这意味每个被解析器返回的地址的子通道。需要注意的是这些策略会忽略任何被解析器返回的均衡器地址。
grpclb策略，工作流如下：