zookeeper在dubbo中的作用

本文旨在表述出自己对于zookeeper在dubbo的作用的初步理解

在对dubbo进行了初步的探索后，对于zookeeper在其中的作用不甚了解，因为本身对zookeeper就没有一个特别具体的概念，所以在这里思考一下，为什么要使用zookeeper或者说dubbo为什么要有注册中心

一对一的调用

Server A依赖Server B提供的RPC服务，因为Server B只有单一的一份，那么此时Server A只需要Server B提供RPC调用的ip和port就可以了

一对多的调用

Server B在用户量日益扩大的背景下，需要进行横向扩展，此时的Server B扩充到了3台服务器：01，02，03

这样做的好处是：

一台宕机，还有两个正常运转的Server可以提供服务；当访问量大的时候，可以进行负载均衡(并不是zookeeper实现的，具体的负载均衡算法需要自己实现，zookeeper能提供给我们的是可用服务列表)

那么对于Server A来说，一下子有3个Server B可以使用，该如何选择呢？如果我选择了01，我还需要去关心，01是不是挂了，01挂了我选择谁呢？

对于Server B来说，我如何进行负载均衡呢？

其实对于Server A来说，我不想要关心Server B的主备情况，我希望Server B的整个分布对于我这个调用方是完全透明的，那么考虑一下这种结构：

其实这个结构很好理解：由于Server B的分布式部署，Server A有选择困难症不知道该选择哪一个B，那么我们就让中间人帮他选并告诉他，然后Server A知道要找谁了，就会去找相关的Server。图中黄色的线代表了注册通知过程，绿色的线代表了调用过程。

例如，Server B的3台服务器都注册一个“获取用户列表”的RPC接口到zookeeper中，Server A作为客户端连接zookeeper，向zookeeper讨要一个“获取用户列表”接口，拿到这个接口的相关信息之后，Server A再去调用具体的Server B的某一台服务器上的服务。即：注册中心（zookeeper）不做实际的方法调用，只做相关信息的传递者。

总结，综上所述，zookeeper自己本身没有负载均衡功能，主要提供服务 发布/订阅 的功能，并通过集群的方式保证服务的一致性和可靠性，但是他的特性可以分布式应用程序基于它来实现类似负载均衡的能力。比如dubbo消费者取得了服务器列表之后，根据一定的选择算法（默认是随机调用）调用其中的一个，就实现了类似负载均衡。

参考文章：https://www.cnblogs.com/shiyu404/p/8945542.html