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）不做实际的方法调用，只做相关信息的传递者。

 

更多需要关注的细节：

• dubbo的在向zookeeper注册服务时，放了些什么数据进去？
• dubbo的负载均衡是dubbo自己做的，还是zookeeper做的？
• ...