我是微服务的新手，所以在阅读它时，在讨论负载平衡时，我无法理解下面的段落，客户端将如何做这样的事情？
“使用客户端发现时，客户端负责确定可用服务实例的网络位置并在它们之间加载平衡请求。”
答案 0 :(得分：4)
微服务架构涉及许多可能具有层次依赖关系的服务。例如，服务A依赖于服务B，服务B依赖于服务C等。同样，每个服务可以有多个实例，并且它们的部署位置可能会动态变化。例如，Service C获得的命中次数过多，您可以动态扩展/缩小此服务。
通常，最终用户无法直接访问任何这些微服务。它只能通过位置固定的边缘服务访问，比如www.microservice.com/apis，并且负责进行身份验证，速率限制等。因此，所有服务调用都将通过边缘服务和加载此阶段的平衡主要是使用硬件负载均衡器或Amazon ELB实现的。
现在，假设用户想要访问服务A.他必须通过边缘服务将请求委托给服务A.服务A必须调用服务B来获取一些信息。在这种情况下，服务A是服务B的客户端，服务A需要找到B的所有可用实例，然后调用其中一个实例。这就是像Consul，Eureka等微服务注册表出现的地方。每个服务实例将不断更新其状态（IP，端口，上/下等）到注册表。边缘服务也将使用此注册表来查找服务A的实例位置。
服务A还应确保对服务B的所有呼叫都是负载平衡的。在这里使用ELB进行负载平衡是不可行的，因为这意味着如果你有50个服务，你需要有50个ELB。有一些软件负载平衡器可以更有效地完成此任务。例如：Ribbon是一个很好的Http客户端库，带有用Java编写的负载均衡器支持。
答案 1 :(得分：0)
客户负责确定网络的位置 可用的服务实例和跨它们的负载平衡请求。
我不确定你在哪里阅读，但服务消费者被迫实施负载平衡的整个概念是荒谬的。
客户端发现模式实际上只是通过服务注册表将延迟呼叫路由（有时是信道构建）推迟到运行时的另一种方式。正如Richardson says在他的模式页面中：
当向服务发出请求时，客户端获取位置 通过查询服务注册表来获取服务实例，服务注册表知道 所有服务实例的位置。
负载平衡是一个完全不同的问题，并且总是被委派，理想情况下是委托给实际负载均衡器，尽管根据您使用的服务平台，您可以访问某种进程内分发服务器。