本文旨在表述出自己对于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）不做实际的方法调用，只做相关信息的传递者。
更多需要关注的细节：
- dubbo的在向zookeeper注册服务时，放了些什么数据进去？
- dubbo的负载均衡是dubbo自己做的，还是zookeeper做的？
- ...