为了建立高度可用的高性能通信服务，通常通过诸如服务注册和发现，负载平衡和耐受耐受性的机制来实施。负载平衡的位置：
服务消费者和服务提供商（通常是专用硬件设备（例如F5）或软件（例如LVS和HAPROXY）等软件之间，有一个独立的LB。这是LB上所有服务的地址映射表，通常由操作注册。和维护配置。当服务消费者调用某个目标服务时，它会启动请求以LB。负载平衡后，将请求转发到目标服务。LB通常具有健康检查功能，并且可以自动删除不健康的服务示例。
该方案的主要问题：
一个点问题，所有服务通话流量都通过LB。当服务数量和呼叫量很大时，LB很容易成为瓶颈，一旦LB失败，它将影响整个系统。
服务消费者和提供商增加了一个水平，并具有一定的绩效费用。
为了响应第一个解决方案的缺点，该解决方案将LB的功能集成到服务消费者流程中，该过程也称为软负载或客户端负载方案。服务提供商启动时，首先将服务地址注册到服务注册表，并定期向服务注册表报告心跳，以指示服务的生存状况，这相当于健康检查。当服务方想要访问某个服务时，它将通过构建的-in -in -ins.lb组件查询服务注册表，缓存和刷新目标服务地址列表，然后使用使用负载平衡策略，并最终向目标服务启动请求。LB和服务发现功能分散在每个服务消费者过程中。同时，服务消费者和服务提供商直接在没有其他开销的情况下被调用，并且性能更好。该方案的主要问题：
该方案是针对第二个方案的缺陷提出的折扣计划，原则基本上与第二个方案相似。差异是LB和服务发现功能从该过程转移到主机上的独立过程。主机上的一个或多个服务希望访问目标服务，他们都使用同一主机上的独立LB进程进行服务发现和负载平衡。此方案也是一个分布式解决方案，而没有单个点问题。LB流程悬挂服务呼叫方仅影响主机。在此过程中，服务呼叫聚会和LB是经过充分称呼的呼叫。同时，该解决方案还简化了服务呼叫，不需要为不同语言开发客户库库。LB的升级不需要服务呼叫方更改代码。
该计划的主要问题：部署更为复杂，有很多链接，错误调试和调查的问题不便。
GRPC开源组件尚未直接提供服务注册和发现的功能实现，但其设计文档提供了实现的想法，并提供了不同语言的GRPC代码API中的命名分析和负载平衡接口扩展。
基本实施原则：
服务启动后，GRPC客户端将名称分析请求发送到名称服务器。该名称将被解析为一个或多个IP地址。无论是服务器地址还是负载Balanner地址，每个IP地址都会标记每个IP地址，并标记了客户负载平衡策略应用于使用客户负载平衡策略器服务配置。
客户的制度化负载平衡策略。如果返回的地址是负载Balanner地址，则客户端将使用GRPCLB策略，否则客户端使用服务配置请求的负载平衡策略。
负载平衡策略为每个服务器地址创建一个子通道（通道）。
当有RPC请求时，负载平衡策略确定子渠道（即GRPC服务器）将接收请求，并且可用服务器作为空客户端的请求将被阻止。
根据GRPC提供的官方设计思想，基于LB解决方案（即第二种情况），与不同的分布式组件（例如Zookeeper等）相结合，您可以找到可行的GRPC服务解决方案发现和负载平衡。
注册的核心逻辑是以名称的形式将服务的启动IP和服务端口注册到基于目标的目标中。因此，当客户端发现服务时，请目标（ETCD）以名称的形式获取IP和端口，Sothe请求将直接在此IP和端口服务器上击中。
服务发现的核心逻辑是根据客户上传的名称检查背部端服务。查询时，将服务注册到GRPC客户端时的值。客户在不夸大网络的情况下直接启动RPC呼叫。
单独开始服务方
开始客户
客户响应：
可以看出，成功的请求三次是不同的服务，表明服务发现和负载余额已生效。
服务器响应：
可以看出，所有三个服务器都响应客户的请求，这仅是一次，并再次证明了负载平衡策略和服务注册已生效
原始：https：//juejin.cn/post/7100968391128645645