grpc python 负载均衡_gRPC客户端负载均衡

让我借此机会通过描述事情应如何运作来回答 .

客户端LB在gRPC C核心(除Java和Go风格或gRPC之外的所有基础)的工作方式如下(权威文档可以找到here)：

客户端LB保持简单并且有意为"dumb" . 我们关注这种情况的方式 . 相反，您只是创建一个通道，它将使用(默认)先选择LB策略 .

LB策略的输入是已解析地址的列表 . 使用DNS时，如果foo.com解析为 [10.0.0.1, 10.0.0.2, 10.0.0.3, 10.0.0.4] ，策略将尝试 Build 与所有这些连接的连接 . 成功连接的第一个将成为所选的一个，直到它断开连接 . 因此名称"pick-first" . 更长的名称可能是"pick first and stick with it for as long as possible"，但这是一个非常长的文件名:) . 如果/当选择的一个断开连接时，优先选择策略将移动以返回下一个成功连接的地址(内部称为"connected subchannel")，如果有的话 . 只要它保持连接，它将再次继续选择这个连接的子通道 . 如果所有这些都失败，则呼叫将失败 .

这里的问题是，基于内在拉取的DNS解析仅在信道创建时触发1)和在断开所选连接子信道时触发 .

到目前为止，一个hacky解决方案是为每个请求创建一个新的通道(效率非常低，但是根据你的设置，它会做到这一点) .

鉴于2017年第一季度的变化(见https://github.com/grpc/grpc/issues/7818)将允许客户选择不同的LB政策，即Round Robin . 此外，我们可能会考虑将"randomize"位引入该客户端配置，这将在对其进行Round-Robin之前对地址进行洗牌，从而有效地实现您的意图 .