如题，现在有一个a服务访问b，但是b是集群的，那么a访问哪个b是在哪里决定的呢，
是在zk里面计算的还是在a处还是在b。
dubbo注册中心返回服务提供者的列表给消费者，消费者从服务提供者列表中，按照软负载均衡算法，选择一台发起请求。
dubbo::reference里可以负载均衡。
zookeeper本身是不提供负载均衡的策略，但是可以在代理层做，如果你前端是dubbo，那么就不需要，dubbo就能做。
当前的微服务和RPC都是在客户端进行负载均衡，dubbo会从zk中获取服务列表，然后在客户端进行选择并建立连接。当机器动态变化，zk会将消息推送给客户端，此时客户端维护的服务列表变化，会基于策略进行修改。
a服务访问b时，b的集群服务列表是通过zk获取，然后访问那个b是在a处自己决定的。就是是客户端自己决定。