客户端的负载平衡Eureka就位后，不同服务将能以动态的方式相互发现，并能直接相互通信，借此可避免负载平衡器代理所产生的开销以及可能的故障点。当然这里也需要进行权衡，因为我们将有关负载平衡的复杂性转嫁到了代码中。
在这里可以看到，DiscoveryLeaderBoardApi.getLeaderBoardAddress方法在每次远程调用过程中，会直接选择找到的第一个ServiceInstance。借助这种方法可以方便地将负载分散到所有可用实例。此外本例中还可以通过Netflix Cloud的另一个组件处理客户端的负载平衡： 。
将Ribbon与Spring Cloud以及现有的Eureka环境配合使用的方法很简单。只需要在logbook服务中添加针对spring-cloud-starter-ribbon的依赖关系，并改为使用LoadBalancerClient取代DiscoveryClient即可：
[url=] [/url]
public class RibbonLeaderBoardApi extends AbstractLeaderBoardApi { private final LoadBalancerClient loadBalancerClient; @Autowired public RibbonLeaderBoardApi(LoadBalancerClient loadBalancerClient) { this.loadBalancerClient = loadBalancerClient; } @Override protected String getLeaderBoardAddress() { ServiceInstance serviceInstance = this.loadBalancerClient.choose("repmax-leaderboard"); if (serviceInstance != null) { return String.format("http://%s:%d", serviceInstance.getHost(), serviceInstance.getPort()); } else { throw new IllegalStateException("Unable to locate a leaderboard service"); } }}[url=][/url]
至此选择ServiceInstance的任务将由Ribbon负责，该功能可以智能地监控端点运行状况，并通过内建机制实现负载平衡。总结本文介绍了各种将微服务连接在一起的方法。其中最简单的方法可能就是将服务所需的每个依存项的地址硬编码到程序中。这种方法可以帮助我们快速上手，但在现实环境中实用性很低。
对于现实世界中最基本的应用程序，通过外部配置使用application.properties文件指定依存项地址这种做法已经足够了。诸如Cloud Foundry和Heroku等平台即服务（PaaS）系统通过暴露连接信息，使得我们能够用完全相同的方式连接这些依赖项。
然而更大规模的应用程序不仅需要简单的点对点连接，还需要使用某种形式的负载平衡。Spring Cloud Config与负载平衡代理的紧密结合是一种解决方案，但如果使用诸如HAProxy或NGINX等市售的负载平衡代理，就只能自行处理服务的发现和注册过程，代理也有可能成为所有流量的一个故障点。通过使用Netflix的Eureka和Ribbon组件，应用程序中的服务将能以动态的方式互相查找，并能将有关负载平衡的决策从专门的负载平衡器代理交由客户端服务来处理。
由于无法控制中间层微服务之间通信产生的传入流量，诸如AWS ELB等负载平衡解决方案在系统边缘可能依然占有一席之地，Ribbon提供了一种不依赖具体的云供应商，可靠性和性能更为出色的解决方案。 |
